Re: Employee modeling question

Поиск
Список
Период
Сортировка
От Nelson Green
Тема Re: Employee modeling question
Дата
Msg-id CAGo-KZ=UxK3T5uwD69xSaTyjvJs_2R+oBdFACRb6uUKK4-HotQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Employee modeling question  (Rich Shepard <rshepard@appl-ecosys.com>)
Список pgsql-general


On Fri, Sep 5, 2014 at 11:39 AM, Rich Shepard <rshepard@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

В списке pgsql-general по дате отправления:

Предыдущее
От: Bill Moran
Дата:
Сообщение: Re: wide row insert via Postgres jdbc driver
Следующее
От: Eugenio Trumpy
Дата:
Сообщение: Re: csv import error