Answer by Jonathan Leffler for schema design
@mson has asked the question "What do you do when a question is not satisfactorily answered on SO?", which is a direct reference to the existing answers to this question.I contributed the following...
View ArticleAnswer by Robert C. Barth for schema design
On data with a lot of writes, (e.g. an OLTP application), it is better to have more, narrower tables (e.g. tables with fewer fields). There will be less lock contention because you're only writing...
View ArticleAnswer by dtc for schema design
I would say the first way looks better.Are there reasons you would want to do it the second way?The first way follows normalization better and is closer to how most relational database schema are...
View ArticleAnswer by Quibblesome for schema design
It depends on the datamodel and the use case. If you ever need to report on a query that wants data out of the "models" then the former is preferable because otherwise (with the latter) you'd have to...
View ArticleAnswer by yfeldblum for schema design
You could try having two separate databases.One is an OLTP (OnLine Transaction Processing) system which should be highly normalized so that the data model is highly correct. Report performance must not...
View ArticleAnswer by Oleg for schema design
Choice depends on required performance.The best database is normalized database. But there could be performance issues in normalized database then you have to denormalize it.Principle "Normalize first,...
View ArticleAnswer by ConcernedOfTunbridgeWells for schema design
Use the former. Setting up separate tables for the specialisations will complicate your code and doesn't bring any advantages that can't be achieved in other ways. It will also massively simplify your...
View ArticleAnswer by Dave Markle for schema design
If the tables really do have the same columns, then the former is the best way to do it. Even if they had different columns, you'd probably still want to have the common columns be in their own table,...
View ArticleAnswer by Onorio Catenacci for schema design
Another thing to consider in defining "better"--will end users be querying this data directly? Highly normalized data is difficult for end-users to work with. Of course this can be overcome with views...
View ArticleAnswer by Paul Mitchell for schema design
Definitely the former example. Do you want to be adding tables to your database whenever you add a new model to your product range?
View ArticleAnswer by Stevo for schema design
Given the description that you have given us, the answer is either.In other words you haven't given us enough information to give a decent answer. Please describe what kind of queries you expect to...
View Articleschema design
Let's say you are a GM dba and you have to design around the GM modelsIs it better to do this?table_modeltype {cadillac, saturn, chevrolet}Or this?table_cadillac_modeltable_saturn_model...
View Article