-1

I am working on redesigning a database for a product called Project Billing. I am having trouble coming up with table names. In the old database, the names were super obscure (PRB_PROJ_LVL), so old is of no help. The database is small - 10 tables or so - but will grow over time.

Here's the problem - Projects are an entity (and table), but the word is also used as an adjetive. Example

  • Project - a table containing projects.
  • ProjectTask - a table containing project tasks; this is a child of Projects.
  • ProjectTemplate - a table for project templates, which is not a child of Projects. Project templates just serve as a model for creating a bunch of ProjectTasks.

So, how do I show that ProjectTask is a child of Project but ProjectTemplate isn't? Thanks as always.

Jasper de Vries
  • 19,370
  • 6
  • 64
  • 102
Mark Williams
  • 583
  • 7
  • 18
  • A real **relational** model will hardly fit in a hierarchy. Or keep in this hierarchy later. You should probably stick with the simplest semantics like "project_template". – Denys Séguret Oct 04 '12 at 14:13

1 Answers1

2

Internal documentation of your schema and its intended use is one of the better ways to do this. Relying on naming convention alone will always leave open the possibility for interpretation - explicit definitions don't do that. That said, we have defined some objects which are intended for use as models (templates in your case). These model objects are not to be used or directly manipulated by the production application and over time are mutable with new objects being based on modified models. One way we tried to apply self-descriptiveness was the introduction of schema. Since we had different departments that could make use of the same model objects, we had something along the lines of (adjusted to apply to your question without assuming too much):

[dept_X].[projects]

[dept_X].[project_tasks]

And for templates, which are never directly used by the application or users (per say):

[model].[projects]

[model].[project_tasks]

As a programming reference for our developers, schema definition scripts contain documentation describing object relationships (as do the objects internally do via foreign keys, etc). As an added measure, a wiki article is generated for all new objects sorted by project. Objects existing prior to this new system (my onboarding) get documented as they get modified or as time permits which ever comes first.

Ray Ayyelos
  • 36
  • 1