One table or many? [closed]

Answer 1

Alot of which would be best depends on how many different fields and the field sizes, you have a restriction on total row size (this can be ignored to some extent knowing that all fields will never all be filled in, but once you get to where the pages are too wide, the actually storage in the datbase ends up splitting the information making retrieval take longer. So if the information is small and (this is important) not likely to change much (it would be a rare event to need to add new type of information not already considered), then the single table is the better route. If the table would be too wide or if it would be subject to many possible changes in the type of data that needs to be stored, then the spearate table would be a better approach although it will always be harder to query properly. If you often want to query multiple types of refernces at the same time, the large table is a more efficient approach. If you usually only need to grab one at a time, you lose very little in terms of efficiency in having the joins.

If you choose to go with the one table route, make sure to put triggers on the table enforcing the data integrity rules for each type of data. You will need this because you can't rely on making the fields required.

One issue with having the separate tables is that you don't know until run time which of the tables you need to join to. This puts you in the realm of dynamic SQl which I'm not a fan of (for security and efficiency and maintenance reasons) or makes you do left joins to tables you may or may not need which is inefficient.

Another possiblity is to store the whole refence string in one larger field and use the user interface to check to make sure all required parts are there before concatinating the record and sending the information to the database. This would be the fastest to query by far for most queries which want all the information but would be a pain if you need to pull only some of the data out. It also relys on all data being inserted through the user interface which may or may not be the case for you. In all honesty, I can't see where you would need this information broken out separately, so this is the approach I'd probably take. But I don't know your business rules, so take that with a grain of salt.

Answer 2

I'd go for having a single table for all references, but additional tables like BookReferences and so on for metadata not applicable for all reference types.

Searching and querying would not be more difficult - after all you could just create a view which aggregates all information as in the single-table solution, and then query that view further.

Having everything in one table with lots of nulls might seem like the simpler solution, but actually it will lead to lots of trouble. For example: With separate tables you can define which fields are required for every BookReference, but if everything is in one table, every field has to be nullable and therefore optional. It would also be easier to insert invalid data, like a book reference which also erroneously contains a non-null journal name.

Edit: Some people seem to fear joins. Don't fear the join! If you use the exact same join in several queries that would indeed be tedious, but in that case the join should be defined in a view, and you queries should query that view. Views are really the basic abstraction in relational databases, and you should use them for the same reasons you use functions in code: to avoid repetition, and to encapsulate and create abstractions.

Edit: There are some comments regarding performance. It's very hard to guess beforehand about performance of DB schemas, because it is often non-intuitive. For example a join between several tables can easily be faster than a full table scan of a single table - it all depends on the type of query, the nature of the data, the available indexes and so on. Additionally, in many database systems you can use features like materialized views to optimize performance for different queries without compromising the logical model. "Denormalization for performance" is mostly cargo cult these days IMHO, unless you are Google or Flickr.

Answer 3

Having single table with "type" field will be problematic when adding a new reference type that needs extra fields. Extending type field values is no problem but you would have to add columns to the table, fill default values for all current rows, etc.

Having separate tables would make it snap-easy to add new reference type (and automatically generate a form for it!) and searching wouldn't be any harder.

Answer 4

I had a discussion about these issues some time ago with my superior. Of course, I couldn't prove that "hierarchical multi-table approach" (see olavk's answer) is better, but I felt it! I would always choose this method. One root table with all the fields that entities have in common, and 1-1 child tables with fields they don't have in common. If need this approach can be extended to more child tables, as long as business logic and other entities will have something out of it. That is, I don't think one needs to go overboard with this.

I'm also against creating separate "child" tables without the root table, where each table has a copy of the same fields. I think Corey's answer suggests such an approach as an example of a bad multi-table model, and he criticizes it as well. I would like to add that having to write joins isn't the main issue with that. It isn't an issue at all, since most of database queries have many joins, and it's a normal thing. It's difficult creating relationships with other tables - you always need an Id and a TypeId to know which table links to it. In the case of a root table, you only need the Id.

Answer 5

How about both? Have your cake and eat it too!

There's another option somewhere between the "one big table" and the "fully normalized" DB that really combines the best of both worlds: You can use something called materialized views, which are like views in that they are just as flexible and you query as many tables as needed, setting up all the joins etc., but they're also like tables in that the results are actually stored in a table.

The nice thing about this is that once you set this up and decide when it is to be refreshed (everytime one of the underlying table sis changes, or maybe just once per night) you don't have worry about it anymore. You can query the materialized view as if it were one big table (because it is), and performance will be fast (faster than using the select statement that is behind it). Most importantly, you don't have the headaches of maintaining data integrity. That's what the DB is there to handle.

If you don't have a DB that supports this out of the box, you can still use this idea by building a table out of the results of the view as a batch job each night.

Answer 6

Rails supports Single-Table inheritance and Polymorphic ActiveRecord types. I would suggest looking into these - ActiveRecord has some opinions on how the database should be structured.