Architecture

One of the things that I dislike seeing in an application’s database architecture is the use of booleans. They do not convey enough information to any party to be meaningful, other than to ask a question that expects a yes/no answer. Often, questions such as those as a follow-up question that the field cannot answer. For example, in many databases I see the following fields on a User model: User ==== id primary key username the user's username credential password_encrypted authenticates the username ... other fields ... enabled true if the user is active, false otherwise When a user has been banned for doing something inappropriate, an application simply sends this query: ...

Not enough people give careful thought about ensuring uniqueness across systems when they design a solution. This goes doubly so for off-the-shelf (OTS) software packages. And if the design isn’t well thought out, it is going to be difficult to ensure uniqueness when doing any data migrations. Granted, data migrations are an art more than they are a science. There are always edge cases and invariably something goes wrong that nobody thought about. This is why testing a data migration multiple times should be built into any project plan (and given an extremely large buffer in the budget). ...