![]() ![]() Those problems are not that big anymore, but there is still a big problem of handling the large number of columns in the code. Though the problem with a table with many columns in RDBMS was hard limits of number of columns (looking at you Access) in tables and a big hit on usage of disk and memory. My suggestion: prototype each method and see how each one feels. ![]() That gives you complete flexibility of which property goes with which object, but comes at the price of poor scaling, but I suppose it's still an option. Or, you could go to the extreme and head down the road (rabbit hole?) of Entity-Attribute-Value. It's not much more complex to manage but it might give you some performance benefits if each subclass has a lot of custom fields (and you never use "select *" in your queries). Or, you could go with a "sub-classing" design, with a core table with all the common stuff, plus a number of other, "extra" tables, one for each subclass of object. You could stick with one table that includes everything, presumably with nullable entries for those that don't apply to all objects. Only you can decide this, based on the needs of your objectd. One solution could be store all required fields in table objects and the rest in table objects_extras? Some features are required for all objects, other only for specific types of objects.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |