Jules Bohanon, Lakeland, Florida:
Repeating data in two tables, e.g., in a customer/sales database, saving the CustomerID and the Customer Name, address, etc. in the "order" table, in addition to having that identifying information in the Customer table. When you change the customer's address in the Customer table, then the old address remains stored in the Order table. Not good. The other major annoyance is the insistence on saving dynamic data in a static field, e.g. Current Balance.
Assem Bayahi, Mourouj 1, Tunisia:
Non use of database options that organise data and enhance database performance: indexes, constraints, views, procedures, column sizes. In general, a generalist programmers don't give importance to those details and focus only on preparing the database skeleton.
Md. Obaidul Haque Sarker, Dhaka, Bangladesh:
I review the database design which is done by a generalist programmer. I review for both the functional and non-functional requirements that must be met. But, they are missing always non-functional requirements such as performance issue. Some programmers designed database is not properly normalized. The review session is done before coding. I recommend the programmer incorporating the review findings.
Christian Koch, Berlin, Germany:
I try to keep the tables in the normal forms (first, second, third ...).
Ven Grollmus, George Town, Tasmania, Australia:
Over the years, one of the biggest lessons I learnt is to have consistent naming conventions across the board, this way you don't get confused, and it helps other developers that may be brought in at a later stage to modify or create additions to the system. This has always served me well. I also try to reuse certain code that isn't proprietary to reduce the effort needed to build a system.