Is it bad practice to use default values in a database? [closed]

Answer 1

You may want to consider what is required to change the defaults. If you application is in house it may not be difficult to change, but if it is on your customers site, then making changes to the database can be a VERY difficult process. If you have hundreds or thousands of clients and you need to convince their DBAs to give you update process SA access to the database you will regret putting any application logic in the DB (including defaults).

Answer 2

Anything you can do in the database is typically more robust. If you handle default values which will be used if no value has been specified only in your app, and someone manages to connect to your database some other way than via your app (and believe me - the users WILL try to connect using Excel or other tools) - then the database is wide open and the user could potentially insert crappy data.

Same goes for referential integrity and check constraints. I believe you're better off if you try to have as many of those constraints on the database - then no matter how the user connects, if he doesn't send you anything, you can put in sensible defaults.

Don't let the application handle your checks - leave that to the database!

Plus it makes your SQL insert statement a lot leaner and meaner if you don't have to specify all the "obvious" defaults, like "getdate()" for a "LastChangedOn" date column etc.

Answer 3

Databases are intended to record assertions of fact.

To allow a user to make incomplete assertions and to have the dbms make silent assumptions about the incomplete part, is plain bad.

If you want robust, reliable systems that can be kept in use for longer times, then don't let any part of that system ever make assumptions about what the user does not say.

Handle defaults at the presentation level and nowhere else. And handle them in such a way that there is no way for the user to not have seen the data he submits (ALL the data !).

Answer 4

Code defaults are easier for unit testing.

Code defaults support multiple scenarios. DB column defaults are a one size fits all. For example, the DB column defaults may vary depending on customer type.

DB column defaults are often opaque to the maintenance developer because they are far away from the INSERT statement, which is usually in the middle tier code, stored procedure, etc. The presence or absence of defaults can be surprising, either way.

DB column defaults defend the database against clients that are too lazy to fill in defaults at all, which is a form of data corruption.

Both kinds of defaults can be subverted by client developers. It is easier to set up barriers to developers using defective defaults in the middle tier. AFAIK, no database lets you require a field take the default value on INSERT. (Edit: a TRIGGER could enforce this but you'd have to copy the default to your trigger and the TRIGGER would overwrite any inserted values with a default) An example of where this might matter is the various tokens people use for a unknown but future date, or an unknown but past date, or it might matter if they use GETDATE() which includes time or if they use a default date with year, month, day and no time.

I'd recommend making sure defaults exist where they make sense in the DB, but don't actually use them. The DB defaults should be the defaults of last resort, and defaults should be solidly in a middle tier (i.e. stored procs, a data access layer). A DB column default is like an exception handler-- when someone forgot by accident to provide a value, what value should be used to prevent data corruption?

Answer 5

As with most "code vs database" arguments, it depends.

If your database (or table) is going to be accessed by a lot of different customers (i.e. teams who don't work closely together), then the database should protect itself. Ideally, everything should be done via stored procedures.

If a single application has access to the database, then that application can contain the business logic. In this case, everything should be done by the one application, and that application accesses the database.

Answer 6

Just the opposite. The database should always provide default values that ensure that records added are valid and meaningful. Remember, you cannot predict at the time you write the application what code will eventually be adding records to the database.

That's not to say that you may not have a second level of default data specified by the application that depends on the application state at the time the data is created.

So, imagine that you have an employee status code that can be "P" (propect), "A" (active), "T" (terminated), or "R" (retired). You should specify at the database level whether people enter the system as "P" or "A", for instance (or perhaps a fifth code for Unassigned). But your application can and should require the user creating the employee record to select one of the options from (for instance) a group of radio buttons and use that value when INSERTing the record.