As a read in lot of links , for e-commerce shopping sites, as it may require to add lot of attributes in regular basis, is it okay if we go with Flat tables ?

Whats the disadvantage of changing database schema or inserting/deleting new columns & tables in middle of the project ?

also Is there any problems if we keep lot of NULL values in database ?

As i heard EAV is Evil , I want to create shopping site with flat tables....

  • 1
    The requirements will change. You will have to either make such changes, or struggle to fit the new features into an inadequate schema.
    – Rick James
    Sep 27, 2016 at 5:59

1 Answer 1


The foundation of your system is your database. If you change your database schema then you also have to change your code. That means that keeping a stable data model helps to reduce the amount of rework you need to do in your code.

Having said that, in the real world requirements change. It's a good idea to invest some time up front to get your data model as good as it can be. After that, the real world will intrude and you'll have to modify your database schema.

With careful planning, you can save yourself a lot of time reworking your code when easily anticipated changes happen.

In terms of Null values, there is nothing wrong with them in and of themselves. However, if you find yourself with a table that has a lot of Null values, it could be a sign that your design is not properly normalized. In a transactional processing system like an e-commerce site, you should start with a database design in third normal form (3NF) and only denormalize with great care and deliberation, and only when necessary. This will help to keep your data quality from degrading.

EAV should be avoided as a general rule, although there are situations where it is a sane choice. I've argued here that online product catalogs is one of those situations.

  • I will partially disagree. Yes, you should try to make the first design reasonably good. But I think you should plan on a major rework of the schema 6 months hence. By planing on it, you will psych yourself into thinking about how to improve it, instead of thinking about how to shoehorn new features/normalizations/etc into the existing schema.
    – Rick James
    Sep 27, 2016 at 5:57
  • @RickJames I don't mean to imply that you should not be ready for major rework of your schema. That is inevitable because your business needs will inevitably evolve. I think my point is not to rush in, slap something up for your schema, and then build a ton of code on top of it without pausing to apply some common sense around what can be reasonably expected to happen. Like the old saying goes: An ounce of prevention is worth a pound of cure.
    – Joel Brown
    Sep 27, 2016 at 13:38
  • Good points. I do agree with you; I was just pointing out other aspects of building a big system. Some day I will poise the question about how "Agile development" can apply to database schemas plus all the code tailored to the schema.
    – Rick James
    Sep 27, 2016 at 15:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.