Re: Normalization question

Of course. If, however, you go down that rabbit hole with your eyes open… Take for example using Employee_Number as I mentioned. If business rules do not allow deletion or changing of this field once it is created, then I see no problem using it as a relational key. For an Employee Number this

Re: Normalization question

Doug, That's a really good resource for ideas for structuring things. I haven't looked at in a long time - it's grown quite a lot. On Wed, Nov 8, 2017 at 12:23 PM, Douglas von Roeder via 4D_Tech < 4d_tech@lists.4d.com> wrote: > This is a link

Re: Normalization question

meaningful can be in context: - a UUID floating alone in an ocean of text has no meaning. - a UUID in a unique (indexed?) field of a relational database has meaning - it is the some identifier - 'Joe' has no meaning, except in context. You might expect that it is a name, but.. Hey Joe, get me

Re: Normalization question

Something that stood out in a recent thread about the definition of the Relational Model was a statement that said related fields should contain meaningful information. This was a surprise, especially since the use of UUIDs has been such a convenience. I took 'meaningful' to imply 'user

Re: Normalization question

** NO ** user definable data should be used as relational/unique key value. generate your own internal values for relations, longint, UUIDs, variations on the Batman Logo, anything that the user has no say in what it is nor how it is used. On Wed, 8 Nov 2017 17:38:38 -0500, Chip Scheide via

Re: Normalization question

Table Project Master Employee Master Project member Project master <- Project member -> Employee master Project member table contains Role (integer) 0=regular member; 1=role A; 2=role B; 3=whatever role Alan Chan 4D iNug Technical <4d_tech@lists.4d.com> writes: >Given a Project table and an

RE: Normalization question

My number three choice that would work in an output form would be this: > [Employees]ID <——— [Projects]PrincipleEmployeeID ><——— [Projects]ProjectMangeEmplyeerID ><——— [Projects]SupervisorEmployeeID Your list form would consist of two or three

Re: Normalization question

John: This is a link to a treasure trove of data models. I checked a couple of the models in the "employees" section and the generic model might provide some ideas.

Re: Normalization question

[Project]<--[ProjectEmployeeType]--> [Employee] ? Keith - CDI > On Nov 8, 2017, at 2:06 PM, John Baughman via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > Given a Project table and an Employee table where Employees can be Project > Principles, Project Managers, and Project Supervisors,