Покритикуйте, посоветуйте.

← →
Knight © (2007-02-27 23:54) [40]

Вот и говорю.. начни с ТЗ... Много чего прояснится для тебя самого %)

← →
AntiUser © (2007-02-27 23:55) [41]

> wicked © (27.02.07 23:49) [38]
> я бы обьединил их с серией и сделал одним varchar-ом
> вкратце - "если над полем по правилам предметной области НЕ ПРЕДУСМАТРИВАЮТСЯ
> арифметические действия, то тип поля нужно делать символьным"например:
> поле "номер дома", "номер накладной" нужно делать символьнымполе
> "коэффициент надбавки", "процент скидки" - числовым

Возможно вы и правы, может объединю.

Спасибо за разъяснение. А это негласное правило?

← →
AntiUser © (2007-02-27 23:57) [42]

> Knight © (27.02.07 23:54) [40]
> Вот и говорю.. начни с ТЗ...

=)
Ну вот, я несколько недель потратил на создание этой БД, а вы мне в середине разработки предлагаете ТЗ написать.

← →
Petr V. Abramov © (2007-02-28 00:01) [43]

> AntiUser © (27.02.07 23:55) [41]
> А это негласное правило?
фактически да. потому что в номерах чего угодно обязательно повится что-либо типа "1а" или "123/испр"

← →
Knight © (2007-02-28 00:04) [44]

> а вы мне в середине разработки

Это ещё несколько недель? Тогда точно проще начать с ТЗ ;)

← →
Petr V. Abramov © (2007-02-28 00:06) [45]

> В Oracle нет boolean"а поэтому пишу False default или True, конечно можно и 0-1 и еще как, но так мне нагляднее.
и будешь по жизни в своем True ошибаться с регистром.

← →
Petr V. Abramov © (2007-02-28 00:10) [46]

> Knight © (28.02.07 00:04) [44]
фигня это все, в данном случае ТЗ умещается в голове, в виде четкого понимания, чего нужно от приложения, а чего нет. А ради базы из 15 табличек бумагу марать не стОит, тем более, что человек один пишет.

← →
Knight © (2007-02-28 00:18) [47]

> [46] Petr V. Abramov © (28.02.07 00:10)

Часто небольшой набросок того что требуется... пусть даже на один-два листа.. и даёт это самое чёткое поимание, особенно в случае "Почему интересуюсь, потому что это мой первый..." :)

← →
AntiUser © (2007-02-28 00:19) [48]

> Petr V. Abramov © (28.02.07 00:06) [45]
> > В Oracle нет boolean"а поэтому пишу False default или
> True, конечно можно и 0-1 и еще как, но так мне нагляднее.
> и будешь по жизни в своем True ошибаться с регистром.

Уговорили =) Потому, что уже один раз столкнулся =)

> Petr V. Abramov © (28.02.07 00:10) [46]
> > Knight © (28.02.07 00:04) [44] фигня это все, в данном
> случае ТЗ умещается в голове, в виде четкого понимания,
> чего нужно от приложения, а чего нет. А ради базы из 15
> табличек бумагу марать не стОит, тем более, что человек
> один пишет.

Во! Действительно! А я тут сижу и думаю как отмазаться =)

Если еще не все потеряли интерес, то с удовольствием выслушаю все точки зрения.
Да же за эти 50 постов, я открыл для себя больше чем за последнюю неделю, работая над этим проектом.

← →
AntiUser © (2007-02-28 00:22) [49]

> Knight © (28.02.07 00:18) [47]

Ну не совсем первый, я же до этого тоже без дела не сидел. Но с таким переплетением связей (особенно как в правом верхнем углу) - первый.

← →
Knight © (2007-02-28 00:23) [50]

Ну да... с таким пониманием, можно и не такого накрутить %)

← →
Knight © (2007-02-28 00:26) [51]

Шутка... не обижайся ;)

← →
ZeroDivide © (2007-02-28 00:37) [52]

> Но с таким переплетением связей (особенно как в правом верхнем
> углу) - первый.

Бывает и такое:
http://patrony-na.front.ru/img/nightmare.jpg

:) Это мое (в соавторстве) творение.

← →
AntiUser © (2007-02-28 00:45) [53]

> Knight © (28.02.07 00:23) [50]
> Ну да... с таким пониманием

Ну с каким - таким? Я-то все это понимаю и для чего связи и с чем, и зачем они связаны - тоже. Но при этом я еще попутно думаю как/какие классы буду создавать, что они будут делать и т.д. Вот и решил здесь спросить перед написанием интерфейса. И, как показала практика, не зря. Опытные глаза сразу выявили ненужные таблицы, про "аттрибутам-значениям, а не аттрибутам свойствам" узнал попутно, связь неверную обнаружил.
Так что, с пониманием - нормуль, главное, чтобы было кому это понимание мне донести, а это и есть эти опытные глаза, которые не одну такую (или примерно) бд слопатили.

← →
AntiUser © (2007-02-28 00:47) [54]

> ZeroDivide © (28.02.07 00:37) [52]

Нет. Такого не бывает =) Такое может только присниться, да и то в кошмаре =)

← →
vuk © (2007-02-28 01:25) [55]

Глянул схемку... Попробую дать совет. Как делается у нас. Для полей в каждой таблице выбирается префикс и имя каждого поля в таблице начинается с префикса. Ну, например, для таблицы Employee логичным выглядит префикс emp. То есть в Вашем примере поля назывались бы:

emp_ID
emp_Surname
emp_Name
...
и т.д.
Что это дает?
1. одно и то же по смыслу поле всегда называется одинаково (у Вас сейчас ID в таблице Employee и EMP_ID в таблицах, которые ссылаются на Employee).
2. Если делаются объединения таблиц, то поля не нужно переименовывать в запросе (в Вашем случае, если делается соединение двух таблиц, содержащих, например, поле Name, одно из полей придется переименовать в запросе).
3. Следствие из (2). Когда Вы глядите на результат запроса, сразу понятно, из какой таблицы поле пришло (префиксы часто легко оседают в памяти).

Про остальное сказать ничего не могу, т.к. выводы можно делать только детально зная ТЗ.

← →
AntiUser © (2007-02-28 08:53) [56]

> vuk © (28.02.07 01:25) [55]

Спасибо, приму к сведению.

← →
Sergey13 © (2007-02-28 08:54) [57]

Почитал по диагонали все предыдущие советы, так что может быть повторю кого-нибудь.
1. Я не увидел иерархической зависимости подразделений и людей. Для кадров это важно.
2. Писать "от нечего делать" на Оракле кадры для малого предприятия - это, ИМХО, полная утопия. Просто кадры (как самостоятельная задача) малому предприятию не нужны - на 10-20 человек никто и не будет это вести. Если предполагается зарплата, то это не отражено и все равно кажется сомнительным нужда в кадровой подзадаче - достаточно списка работников. Ну и юзать Оракл для малого предприятия - тоже ИМХО слишком уж круто. Т.е. налицо явный маркетинговый просчет. А для большого предприятия - там все несколько сложнее устроено (насколько я помню - я курировал подобную задачу) и этой схемки будет явно недостаточно. Т.е. все это нормально (с учетом замечаний) для курсового проекта или просто экзерсисов для самосовершенствования, но явно недостаточно для какого-либо реального внедрения.

← →
Empleado © (2007-02-28 11:36) [58]

> AntiUser © (27.02.07 20:18) [6]
> > Empleado © (27.02.07 19:14) [2]
> Да, может. О том, какой активный - не подумал, возможно
> рационально.

Возможно стоит указать obsolete, т.к. активных паспортов может быть несколько.
Например, у Гусинского их теперь три :)

> > Empleado © (27.02.07 19:18) [3]
> А как же описать связь?

Добавить emp_id и соответствующую связь в таблицу passport?

← →
Empleado © (2007-02-28 12:10) [59]

Возможно повторюсь, т.к. возможно пропустил что-то из уже сказанного выше:

1) таблица passport_name. Я так понимаю, что это passport_type?

2) таблица emp_additions
Если никакие другие таблицы на нее не ссылаются, может сделать PK из (emp_id; ord_id), а id совсем выбросить?
Смотри по аналогии orders_on, где id нужен; а вот уже в otdel_job - id фактически не нужен, и можно сделать PK из трех полей;
и т.д. для всех подобных ситуаций

3) orders_name - это orders_type? :))

4) таблицы job, otdel, orders;
Зачем нужен ord_id в otdel? По данному смыслу: он показывает к какому Заказу принадлежит Отдел - что не имеет смысла.
Можно добавить еще одну таблицу отношений между otdel и orders, например: orders_per_otdel (otdel_id, ord_id; PK = [otdel_id, ord_id]), и сослаться на эту таблицу из otdel и orders. Тогда ord_id можно убрать из otdel.
Если уж надо оставить так по каким-то соображениям, то: С подобной связью не всегда удобно программировать.

5) address: Адрес не имеет номера телефона. В общем случае телефон прикреплен к человеку (НО, возможно я ошибаюсь!)

6) Если уж идет растасовка на адреса (домашний, рабочий, адрес доставки товара, временный и т.д.), то почему нет подобного для communication devices, например? Т.е. Один человек может иметь: сотовый (а иногда и два), факс, е-mail, телефон жены/тещи, skype account и т.д....

7) что показывает связь между job и orders?

Всего доброго.

← →
Empleado © (2007-02-28 12:28) [60]

Пересмотреть связку таблиц: employee - otdel_job - job - otdel

Дано:
Работнички (одна таблица)
(Q: Один работник может быть одновременно в двух и более отделах?(PS. у нас в конторе - может))
Должности (одна таблица)
(Q: Один работник может занимать две и более должности?)
Отделы (одна таблица)
(Q: Список должностей по отделам - так ли он необходим?)
Заказы (одна таблица)
(Q: От чего зависят заказы?)

Остальное - отношения между ними, описанные, в общем случае, отдельными таблицами (но необязательно - зависит от смысла), ссылающимися на эти четыре.

ПС. "Q:" - вопрос на обдумку :))

Всего доброго.

← →
DrAndrey © (2007-02-28 15:22) [61]

Писал "Кадры" 2 года назад для организации 450 сотрудников, структура значительно сложнее - 74 таблицы. Времени ушло почти год (долго придумывал саму концепцию), но заказчик очень доволен, потому что прога специфическая, под конкретное учреждение. Цена вопроса 250$, больше она и не стоит.

Начни с изучения документов, в первую очередь Трудовой кодекс РФ, ОКИН, ОКСО и т.д. Очень помогло изучение аналогичного ПО от "ОАЗИС" и 1С, журнал "Справочник кадровика", инструкция МО "О постановке на воинский учет" и др. ведомственные документы.

Все отделы в одну таблицу с ID, Parent_ID.

Имена полей лучше русские транслит. т.к., могут быть сложные термины, перевести и коротко записать которые проблематично.

Есть такая штука "Личная карточка", знаешь?

> Sergey13 © (28.02.07 08:54) [57]
> 1. Я не увидел иерархической зависимости
> подразделений и людей. Для кадров это важно.

Возможно вы и правы. А ка это лучше оформить? В виде поля с приоритетом 1,2,3 и т.д.?

> Empleado © (28.02.07 11:36) [58]

С этим ясно.

> Empleado © (28.02.07 12:10) [59]

1. Да.
2. В общем, может вы и правы. Подумаю. Спасибо.
3. Да.
4. ORDERS, это приказы.
5. В общем случае телефон прикреплен к человеку (НО, возможно я ошибаюсь!)
Да, скорее всего, то что в скобках ;)
6. За допонительные телефоны отвечает таблица TELEPHONE. Об этом выше обсуждалось.
7. Приказы по должности.

> Empleado © (28.02.07 12:28) [60]
> Пересмотреть связку таблиц: employee - otdel_job - job -
> otdelДано: Работнички (одна таблица) (Q: Один работник
> может быть одновременно в двух и более отделах?(PS. у нас
> в конторе - может))Должности (одна таблица) (Q: Один работник
> может занимать две и более должности?)Отделы (одна таблица)
> (Q: Список должностей по отделам - так ли он необходим?)Заказы
> (одна таблица) (Q: От чего зависят заказы?)

На все Q - да, кроме последнего, это не заказы, а приказы.

> DrAndrey © (28.02.07 15:22) [61]
> Есть такая штука "Личная карточка", знаешь?

Про прочтение, это хорошо, но не сейчас, т.к. задача стоит проще и (в основном) пишется дляприобретения навыков создания БД.

Про "Личная карточка" незнаю. Что это?

Личная карточка - это для гос. и муницип. организаций обязательная регистрационная форма, которая заполняется на каждого сотрудника.

>Про прочтение, это хорошо, но не сейчас...

После того как сотряпаешь базу по своей чудовищной схеме, читать уже будет поздно. А если <для приобретения навыков создания БД>, то на мой взгляд, задача слишком сложная. Поверь мне, когда я начинал свои "Кадры", то тоже думал, что все так просто и быстро.

> DrAndrey © (28.02.07 18:23) [63]

Так у вас БД была под заказ, ха деньги, по ГОСТ"ам, а у меня для освоения принцыпов бд.

> [62] AntiUser © (28.02.07 18:14)

> А ка это лучше оформить? В виде поля с приоритетом 1,2,3 и т.д.?
Нет. Классический способ - поля Id и Parent_Id. Второе ссылается на первое. В Оракле такая структура на ура раскручивается через запросы с connect by.

>4. ORDERS, это приказы.
ОК.
Тогда получается, что отношение otdel --> orders указывает на Приказ, на основании которого отдел был создан? (т.к. возможна ссылка из Отдела только на один Приказ)

Есть приказы. А дальше - все, что ссылается на них: кем выдан, на кого распространяется и т.д.
Есть отделы....

>>7) что показывает связь между job и orders?
>7. Приказы по должности.

Переименовать ВСЕ таблицы!!! :)) Не шучу!

А вот еще автору ветки вопрос на "подумать".
Ситуация: Приказом A работник B переведен с должности C на должность D. Что делать будете?

> Sergey13 © (01.03.07 08:35) [65]

Т.е. дерево?

> Empleado © (01.03.07 11:32) [66]
> Переименовать ВСЕ таблицы!!! :)) Не шучу!

На счет приказов по отделу - да. Но типы приказов могут быть разные. В общем надо подумать.

Про переименовать. И как вы себе это видите?

> vuk © (01.03.07 12:07) [67]

Обязательно отвечу.

Просто сейчас 39 температура, не до этого, извиняйте.

> vuk © (01.03.07 12:07) [67]
> А вот еще автору ветки вопрос на "подумать".Ситуация: Приказом
> A работник B переведен с должности C на должность D. Что
> делать будете?

А чего думать-то, работника А снимаем с должности С на основании приказа А и назначаем на должность D на основании того же приказа.
А как вы это видите?

Покритикуйте, посоветуйте. Найти похожие ветки