• ca.zerbe-heinrich - Wednesday, January 17, 2018 12:27 PM

    Hi all!

    Using this oportunity to wich you a happy new year!

    Now my question!
    We are developing a C# application, using MS SQL database for the objects and data (Entity Framework for ObjectMapping, as far as I know).

    Now I am faced with a database Migration which redefines one column (RAW data format, from NULL to NOT NULL) in the biggest table inside the database (my assumption is: about 80% to 85% of the used data).

    Because the database itself (recovery model FULL) increases by the size of that table (GUID and RAW column), I told the developers, that we can not "sell" this to any customer, but use a "CONSTRAINT" (check for not null or > 0)) instead.

    The fast response was.
    We do not care, we develop. It's your problem.
    AND FOR PERFORMANCE REASONS, the database management system will perform better when the table definition for the RAW column is "not null", instead of the added CHECK CONSTRAINT (checking the data for being not null).

    Can you verify this Statement?

    Hope you have a quick answer for me!

    Kind regards,
    C.-A.

    The argument itself doesn't make a lot of sense to me personally. How does using the not null property vs using a constraint lead to size issues that have some impact to customers - especially when either way, some value is going to be entered? And likely the same value whether with a constraint or not null?
    I'd be more concerned about using Entity Framework. 

    Sue