Field naming best practices (unique or not)

Hi @akavenventures,
I feel that field names should be descriptive of the field’s content. I see no harm in using the same name in another table if that is what makes sense.

When you are doing look ups and roll ups the default field name can get long and I usually change it to something that makes sense.

For fields that I intend to hide like calculation fields I typically name with the first word lowercase: dateFormula

As you know, you can’t give two fields in the same table the same exact name. But you can certainly use the same name for fields in different tables and there’s no general reason NOT to. For example, in a base I’m working on presently for a school, there are two tables PARENTS and STUDENTS. I use the same field labels for personal names in both tables: NameFirst, NameMiddle, etc.

But that brings up a consideration that lately I’ve seen a number of new users fail to make. It’s not wrong to use the same label for fields in different tables, but it’s not common. If you’ve properly modeled your data, things of the same kind – the same “entities” – will be in the same table, and the properties of one the things in table A don’t very often overlap with the properties of things in table B. The properties of a record in WIDGETS are unlikely to be be very like the properties of a record in SUPPLIERS.

(There’s one clear exception to that rule, which is when you create a duplicate of table A to store, say, records from table A that you’ve marked for later deletion; or an archived records table. But generally you can achieve nearly the same thing with a single table, + something like a status field, + well-defined filters. And keeping everything in the same table obviates a problem likely to occur when you clone a table, that is, if it’s valuable to have the fields in both tables be identically named, then you’re going to have to be very careful if you ever decide to rename a field in one table.)

In my example above of the school database, parents and students are NOT the same “thing”, i.e. they are not united in being “persons”. They are distinguished by totally distinct rules. And in fact, in that database, in some cases, a person who was once a student has since become a parent whose children are not attending the school. In that case, a record referring to that person is found in both tables.

Database nomenclature is one of the most vexed topics developers have to deal with. The single most important consideration is consistency. Inconsistent naming practices (whether for tables or fields) will confuse not only your users but you, too. That’s not to say there aren’t other important considerations. There certainly are, and I think there are clearly better and worse systems. But advanced and experienced developers differ about these things so it seems the main thing is, work at it for a while and find what works for you, what you’re comfortable with, and do that.