Do you DB designers out there typically build detailed field specifications as part of your design process? How detailed to you get?

One of my reference books goes into great detail. I've followed this track as a learning exercise -- and it's been a worthwhile exercise. So, I'm wondering if I should fill out field specs for every project.

my design process comes in two stages -- logical design and physical design

in logical design, i might note that the Persons table needs to record people's addresses, and leave it at that -- address being the logical attribute

during physical design, i flesh this out to actual columns, datatypes, constraints, etc.

yes, specifications require detail (especially if you are handing them off for someone else to implement)

but don't try to do everything at once

Working on a large project, we always specify our tables in detail using a CASE tool from which we eventually crank the DDL to create the tables.

For a very small project I might not go into such detail before creating the tables - though you still need to be careful to ensure you are consistent with column datatypes and sizes in different places (e.g. foreign keys).

When I was new to analysis and database design I used to use all the (paper-based) tools I had been taught: ERDs, FHDs, DFDs, entity life histories, CRUD matrices, who knows what else. It probably was useful to me at the time, giving me confidence that I'd covered all the bases. With experience, I learned to skip some of these entirely, or to use them judiciously in special cases. I'm still rather partial to ERDs though.

heh - you said "CRUD"