database-schema

I've got a database which will store profiles about individuals. These individuals have about 50 possible fields. Some are common things like, first name, last name, email, phone number. Others are things like hobbies, skills, interests Some are height, weight, skin color. Each of these groups are used by the system at different times. In terms of being able to negotiate through the database I would prefer to have 7 tables each of about 8 fields. What is best practice to do? EDIT: The data is going to be used in a search engine, for finding profile matches. Does this affect what I am doing? It

How do I instruct mysqldump to backup with column names in insert statements? In my case I didn’t a normal back up with insert sql’s resulting in LOCK TABLES `users` WRITE; /*!40000 ALTER TABLE `users` INSERT INTO `users` VALUES (1 structure. Now I went ahead and removed a column from the schema in users. After this when I run the backup sql’s I get a column number mismatch error . To fix this how do I go about instructing mysqldump to write column names too? Here is how I do it now mysqldump --host=${dbserver} --user=${dbusername} --password=${dbpassword} \ --no-create-db --no-create-info -

I've seen SaaS applications hosted in many different ways. Is it a good idea to split features and modules across multiple databases? For example, putting things like the User table on one DB and feature/app specific tables on another DB and perhaps other commonly shared tables in another DB? Start with one database. Split data/functionality when project requires it. Here is what we can learn from LinkedIn: A single database does not work Referential integrity will not be possible Any data loss is a problem Caching is good even when it's modestly effective Never underestimate growth trajectory

I'm trying to draw an ER diagram for my project management software describing the following. It contains these entities: project - software projects tasks - software projects that can be broken into a number of tasks employees - employees that belong to this software And: A project can be divided into tasks. (Tasks can be created by the admin user, who can assign those tasks to selected projects. Here there is only assignment of tasks to projects, not assignment of employees to projects.) Employees can be assigned to projects. (An employee can be assigned to projects. Here there is only

For my surprise, using the CreateDatabaseIfNotExists context initializer, the line context.Database.Initialize(true) doesn't throw an exception if the schema does not match my code first schema. Is there a way to validate if the current database matches our schema before, for instance, we try to access a entity, whose table doesn't exist on the database anymore, and an exception is thrown by EF? You can call CompatibleWithModel to determine if the database matches the model. If you set the parameter to true it will throw an exception if no model data is found in the database. bool isCompatible

I have made a model change from standard = models.ManyToManyField(Standard) to standard = models.ManyToManyField(Standard, blank=True, null=True) South schemamigration for this app doesn't recognize the change? Similar to this question, which is unanswered: South migrations and changes to many-to-may fields That behavior is correct: null doesn't mean anything at the database level when used with a ManyToManyField . The declaration of a ManyToManyField causes the creation of an intermediate table to hold the relationship, and although Django will create a standard attribute on your model