On Fri, Sep 5, 2014 at 11:39 AM, Rich Shepard <rshepard@xxxxxxxxxxxxxxx> wrote:
Although I have not completely hashed this whole situation out, I am leaning
towards an exclusivity constraint on department and business, where one of the
columns will be required to be null, and a check constraint on the business
column that will not allow businesses that are referenced in the department
table. This seems to meet all of my rules and requirements, and will also work
in the case of external contracts applying to a business or a department.
If this plan changes dramatically I will update this posting, and I do
appreciate the advice that I received from you and everyone else. I especially
appreciate being given pointers to information sources as opposed to receiving
pat answers without explanations. Reading and learning will prove much more
beneficial in the long run.
Well, back to work. Gotta go explain to someone why two separate and unrelated
tables won't model their multi step workflow too well (OK not at all really). I
just love how people that can populate a spreadsheet think that makes them into
data professionals.
Nelson
On Fri, 5 Sep 2014, John McKown wrote:
They are excellent. They are _not_ for beginners. The "For Smarties"
portion is not just a play against the "For Dummies" series. Joe does some
high powered SQL.
For the purpose of developing an employee schema with departments for
some, his "SQL For Smarties" provides very sound advice on how to proceed.
Having separate company, department, and employee tables is a given. But,
you might need many-to-many tables to keep track of the complex
relationships. This is all covered in the chapters on DDL (Data Definition
Language) and is separate from the chapters on DML (Data Manipulation
Language).
Good luck,
Rich
Thank you Rich, and apologies for the delay in getting back to this. Sometimes
my job has a bad habit of getting in the way of getting work done.
I've been through the first four or five chapters of the SQL For Smarties book,
and I've glanced at the other two books we have, but I didn't find anything
especially enlightening (and I was surprised at the number of typographical
errors in the content). I have also read through the other references I was
my job has a bad habit of getting in the way of getting work done.
I've been through the first four or five chapters of the SQL For Smarties book,
and I've glanced at the other two books we have, but I didn't find anything
especially enlightening (and I was surprised at the number of typographical
errors in the content). I have also read through the other references I was
given.
Although I have not completely hashed this whole situation out, I am leaning
towards an exclusivity constraint on department and business, where one of the
columns will be required to be null, and a check constraint on the business
column that will not allow businesses that are referenced in the department
table. This seems to meet all of my rules and requirements, and will also work
in the case of external contracts applying to a business or a department.
If this plan changes dramatically I will update this posting, and I do
appreciate the advice that I received from you and everyone else. I especially
appreciate being given pointers to information sources as opposed to receiving
pat answers without explanations. Reading and learning will prove much more
beneficial in the long run.
Well, back to work. Gotta go explain to someone why two separate and unrelated
tables won't model their multi step workflow too well (OK not at all really). I
just love how people that can populate a spreadsheet think that makes them into
data professionals.
Nelson
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
