Jules Bohanon, Lakeland, Florida:
Can't think of any offhand.
Assem Bayahi, Mourouj 1, Tunisia:
Generally none, but sometimes you are obliged to save the same data in two different places.
Md. Obaidul Haque Sarker, Dhaka, Bangladesh:
I have about 10+ years experience in database design and development. Initially [before 5 years], I forgot to create the indexes and foreign key constraints during database design. But Now I am doing all of things during DB design. I prepared a checklist for DB design. I review the design as per my checklist. If anything I missed, I will incorporate it before coding started.
Mark Horner, Bristol, England:
Hmm, N/A here
Ven Grollmus, George Town, Tasmania, Australia:
If needed, and usually at a client's request, I will move away from the standard naming convention that I use to the client's requirement. In doing this, I do maintain a dictionary of the naming conventions that is given to the client so that they can give it to new programming staff in the future if needed.
Bruce Bray, Phoenix, Arizona:
Probably storing objects inside of a database. I still prefer to store objects in the file system and create indexes to find these objects. It just makes everything cleaner and faster.
Yuriy Sultanaev, Ufa, Russia:
Boyce-Codd normal form
Temitayo Ilori, Berea, Ohio:
A lot of textbooks teach that referential integrity should be avoided most of the time. I break this. I always enforce referential integrity. It helps to avoid inconsistency of data.
Julie Hogue, Akron, Ohio:
I am extremely proficient with VBA coding. I prefer to avoid using macros and queries and like to embed the logic directly within the forms or modules. I have worked on systems that previous programmers have designed that are not proficient with VBA. They may use 10 queries to achieve what I do in one central location. I waste a lot of time tracking and verifying the correctness of their queries.
Grace Elaiza Seballos, Davao City, Philippines:
Sometimes, I have to weigh things between getting a table normalized, or fitting it in such a way, that once I create a query for it, it will be easy. One example would be an "inventory" table. The inventory table have a child table where the inventory movement history takes place (whether adding or removing inventory for that bin). I should not put the quantity left on the parent table, because it can already be computed from the child table. But for simple query purposes (especially when making statistical reports), it can be more beneficial to add the quantity field on the parent. But this is still a case to case basis, for the reason that all RDBMS support Views already. Therefore, I can create Views (ready for the reports) instead of querying directly to the table. It is much faster and more reliable.
Artiben prashantbhai S., Bhavnagar, India: