On Fri, Sep 5, 2014 at 11:39 AM, Rich Shepard <rshep...@appl-ecosys.com> wrote:
> 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 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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >