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

← →
AntiUser © (2007-02-27 19:00) [0]

Принимаю любые замечания, наставления, критику, советы, как что, можно было бы, а может быть и нет, сделать лучше.
Проект БД: http://antiuser.pisem.net/temp/table1.gif

Почему интересуюсь, потому что это мой первый, достаточно сложный проект по проектированию и дальнейшему созданию интерфейса. Вот, собстно, поэтому и хотелось бы услышать аргументированные мнения профессианалов, по, возможным, ошибкам, недочетам, излишествам, что бы в дальнейшем создание интерфейса не стало, ну очень большим геморроем.
К тому же, хотелось бы, что бы вы обратили внимание и на названия полей/таблиц, что бы подсказать мне единый (читай правельный) стиль оформления. Ну и т.д и т.п.

В общем, слушаю. (правда, отойду пока, но я вернусь =))
Зарание, спасибо.

← →
oldman © (2007-02-27 19:07) [1]

Замечание №1: Мне не понравился зелененький цвет.
Замечание №2: А можно хоть какое-то объяснение, что это за нафиг...

← →
Empleado © (2007-02-27 19:14) [2]

> AntiUser © (27.02.07 19:00)

Один employee может иметь несколько паспортов? (см. passport_pn)

Если "нет", то passport_pn убрать, а emp_id добавить в passport;
если "да" (в том числе для статистики предыдущих, например), то надо, чтобы было понятно - какой passport действителен в настоящее время и на какой passport надо делать упор (загран, внутренний, иностранный (при многогражданстве)).

дальше - завтра, труба зовет!
bye

← →
Empleado © (2007-02-27 19:18) [3]

>Empleado © (27.02.07 19:14) [2]
ПС. да в любом случае passport_pn можно удалить

← →
Gero © (2007-02-27 19:18) [4]

Тени убери, они только перегружают картинку. Заголовки выделяй, например, жирным.

← →
Gero © (2007-02-27 19:20) [5]

Насчет правильности выбора цветов ничего сказать нельзя, имея только это изображение.

← →
AntiUser © (2007-02-27 20:18) [6]

> Empleado © (27.02.07 19:14) [2]

Да, может. О том, какой активный - не подумал, возможно рационально.

> Empleado © (27.02.07 19:18) [3]

На каком основании? А как же описать связь?

> oldman © (27.02.07 19:07) [1]
> Замечание №1: Мне не понравился зелененький цвет.
> Gero © (27.02.07 19:18) [4]
> Gero © (27.02.07 19:20) [5]

Само изображение меня не интересует. Могу хоть от руки нарисовать, для вас же старался, что бы читаемо было.

Интересуют мнения по поводу содержания.

> oldman © (27.02.07 19:07) [1]
> Замечание №2: А можно хоть какое-то объяснение, что это за нафиг..

Это небольшая БД, типа кадры. Человек - данные (проживание, образование, паспорт, должность, приказы), все они (кроме некоторых приказов) завязаны на человека

← →
default © (2007-02-27 20:23) [7]

ты прогу пишешь типа ERwin?
можно поговорить
я тоже такую пишу

← →
Petr V. Abramov © (2007-02-27 20:26) [8]

А зачем все NAME выделены в отдельные таблицы?
а по мелочи - все таблицы названы по-английски, а OTDEL - по-непонятному :)

← →
AntiUser © (2007-02-27 20:31) [9]

> default © (27.02.07 20:23) [7]
> ты прогу пишешь типа ERwin?

Нет не пишу. Я пытаюсь создать базу данных. Эта картинка описывает таблицы, поля и их связи. Поскольку я делаю такую задачу в первый раз, поэтому и спросил мнение.

По поводу картинки. Она создана с помощью PowerDesigner 11, а саму базу делал в PLSQL Developer"e.

← →
AntiUser © (2007-02-27 20:35) [10]

> Petr V. Abramov © (27.02.07 20:26) [8]
> А зачем все NAME выделены в отдельные таблицы?а по мелочи

Предполагается наличие нескольких имен, за сим связь ...

> - все таблицы названы по-английски, а OTDEL - по-непонятному
> :)

Да фиг знает =) Как-то получилось само собой. Пока это прототип, поэтому и советуюсь. Наверное переделаю, а то действительно, как-то не так ;)

← →
Petr V. Abramov © (2007-02-27 20:38) [11]

> Предполагается наличие нескольких имен, за сим связь ...
у паспорта и у адреса? ну тебе видней предметную облать

← →
AntiUser © (2007-02-27 20:49) [12]

> Petr V. Abramov © (27.02.07 20:38) [11]
> > Предполагается наличие нескольких имен, за сим связь .
> ..у паспорта и у адреса? ну тебе видней предметную облать

Ну а как место прописки и место проживания могу отличаться. Так ведь?
Обязательное наличие российского паспорта, а так же возможность наличия загранпаспорта, тоже, думаю никто не оспорит, а для командировок за границу, можно посмотреть наличие этого паспорта. Соответственно люди уже имеющие его будут иметь приоритет перед теми у кого его не будет, при одинаковых других условиях.

← →
Knight © (2007-02-27 20:49) [13]

> [11] Petr V. Abramov © (27.02.07 20:38)

Местный, Загран, временный, спёртый...
По прописке, фактический, возможные (квартиры для... , явки и пр.)

← →
Petr V. Abramov © (2007-02-27 21:02) [14]

> AntiUser © (27.02.07 20:49) [12]
дык то, что адресов и паспортов может быт несколько - понятно. Но как у конкретного экземпляра паспорта(адреса) может быть несколько названий? Или это ТИП адреса? тогда что значит стрелка - откуда она растет, там "один" или "много"?

← →
Knight © (2007-02-27 21:14) [15]

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

Да... заюзано не так..

← →
AntiUser © (2007-02-27 21:29) [16]

То есть? Стрелки не в ту сторону? А я, вроде, сначала так и сделал, но потом мне показалось это не совсем верным.
Я, как бы предполагаю так.
Есть PASSPORT имеет свой ID и PASS_NAME_ID, который указвает на запись с названием паспорта.
А как должно быть?

← →
Petr V. Abramov © (2007-02-27 21:35) [17]

> который указвает на запись с названием паспорта.
что такое "название". если "местный", "заграничный", тогда это ТИП, и так и назови, не смущай народ. Если "первый загранпаспорт Васи" - тогда нечего отдельную таблицу городить (в данном случае, изредка полезно из соображений перфоменса).
А куда стрелки - дело вкуса, главное, чтоб везде одинаково. Но, ИМХО, обычно стрелка растет от "один" указывает на "много"

← →
AntiUser © (2007-02-27 21:42) [18]

> Petr V. Abramov © (27.02.07 21:35) [17]

Ну да, все как Вы говорите. Стрелки растут куда надо =)
Ну раз ТИПЫ, так пусть будут ТИПЫ, это принципиально? Надо ли это отразить в базе? Например, вместо PASSPORT_NAME сделать PASSPORT_TYPE и поле соответственно?

← →
Petr V. Abramov © (2007-02-27 21:49) [19]

> Ну раз ТИПЫ, так пусть будут ТИПЫ, это принципиально?
да можно и горшки, только непонятно, NAME больно заезженное слово, вот сразу не въехал, что имлось в виду.
> Стрелки растут куда надо =) да откуда я знаю, куда им надо? Конец стрелки (куда она указывает) - это "один" или "много"?

← →
AntiUser © (2007-02-27 21:57) [20]

> Petr V. Abramov © (27.02.07 21:49) [19]
> Конец стрелки (куда она указывает) - это "один" или "много"?

Это "один". Если я все правильно понимаю, т.е. PASSPORT_NAME.NAME = "Российский паспорт", а PASSPORT - их много, по крайней мере, подразумевается, что все сотрудники имеют паспорта российского образца.
Т.е. у меня, что-то не так? Я правильно понимаю?

← →
AntiUser © (2007-02-27 21:58) [21]

На самом деле меня больше беспокоит этот огород с должностями, отделами и приказами.

← →
AntiUser © (2007-02-27 22:01) [22]

Что-то интуиция мне подсказывает, что там что-то не так =(

← →
Knight © (2007-02-27 22:03) [23]

А почему бы не добавить поле ИмяПаспорта к ПАСПОРТ_ПН ?

← →
Knight © (2007-02-27 22:06) [24]

И действительно для чего нужны эти PASSPORT_PN и ADDRESS_NA ?

← →
AntiUser © (2007-02-27 22:07) [25]

> Knight © (27.02.07 22:03) [23]
> А почему бы не добавить поле ИмяПаспорта к ПАСПОРТ_ПН ?

Теоритически можно, но встает проблема простого и удобного редактирования списка типов (паспортов, адресов, образований, приказов).

← →
AntiUser © (2007-02-27 22:09) [26]

> Knight © (27.02.07 22:06) [24]
> И действительно для чего нужны эти PASSPORT_PN и ADDRESS_NA
> ?

Я тоже над этим думал, не нравились они мне, но решил оставить.

Значит, все-таки лучше убрать?

← →
Knight © (2007-02-27 22:09) [27]

Имена адресов и паспортов пусть в справочниках, а сами паспорта и адреса сделать по принципу телефонов.. а к телефонам привязать справочник типов телефонов (рабочий, домашний, сотовый...)

← →
Knight © (2007-02-27 22:11) [28]

То же самое по отношению к верху (FORMATION)... %)

Переведите названия таблиц правого-верхнего сектора... чё-т я не въезжаю..

> Knight © (27.02.07 22:09) [27]

Понял. Но с телефонами сознательно, поскольку в TELEPHONE будут содержаться только те, которые не относятся к адресам (в ADDRESS есть спец. поле), рабочих телефонов не будет. Остаются только сотовые, поэтому справочник типов для телефонов делать не стал.

> Knight © (27.02.07 22:16) [29]
> Переведите названия таблиц правого-верхнего сектора... чё-
> т я не въезжаю..

Да, там фигня, сам путаюсь, потом переделаю.
FORM_PROFESSIONS ... ща в коментах посмотрю =)

А вот посмотрел, там действительно ошибка.
FORMATION - справочник типов образований (среднее, высшее и т.д.).
FORM_PROFESSIONS - профессия по образованию.

Это левый-верхний... а я спрашивал ПРАВЫЙ... похоже не мне одному спать пора... :)))

общие замечания:
1) язык, на котором именованы обьекты БД - все таки хорошо бы использовать один, английский либо русский (транслитом ;))
2) "число" в названиях обьектов - employee и address - в одиночном, orders - во множественном.... это приведет к сложностям при запоминании имен обьектов - не все время ж в схему подглядывать?
3) длинные названия обьектов (как по мне) - telephone вполне можно сократить до phone;
и еще - система только телефоны будет хранить? а емейлы, аськи, скайпы, пейджеры? и на каждый из них новую таблицу?
4) выбор типов данных для некоторых полей - зачем в passport числовое значение num? предполагается выбор sum(), min(), max(), avg() по этому полю?
есть такое правило - числовые типы нужно назначать только аттрибутам-значениям, а не аттрибутам свойствам
и зачем для поля job.deleted выделять аж 5 символов?
5) разбивка по полям - зачем в address вынесены отдельно поля korpus, house и street? мы будем искать всех тех, кто живет в "корпусе 2"? аналогично с series и num в passport
6) связки между таблицами - смущает меня что то двойная связка orders и employee через таблицы orders_on и emp_additions - здесь надо что то пересмотреть
7) повальное использование автоинкрементных числовых ключей даже там, где можно обойтись символьными не-автоинкрементными; например, связки между address и address_name, passport и passport_name
но этот пункт уж больно сомнительный

пока вроде всё - это еще не все замечания, а только часть, которая пришла в голову

Имхо... упразднить OTDEL_JOB, ORDER_ON и связку OTDEL-ORDERS

Что такое EMP_ADDITIONS тоже не совсем понял... поэтому, предлагаю тоже можно зарезать :)

> Knight © (27.02.07 22:42) [34]
> Имхо... упразднить OTDEL_JOB, ORDER_ON и связку OTDEL-ORDERS

OTDEL_JOB нельзя, там совмещение, а вот связь надо переписать на ORDERS
ORDER_ON нельзя, приказы напрямую связанные с сотрудником, например, выговор, поощрение, награждение и т.д.
OTDEL-ORDERS нельзя, при расформировании/создании отдела, должен быть приказ.

> Knight © (27.02.07 22:47) [35]
> Что такое EMP_ADDITIONS тоже не совсем понял... поэтому,
> предлагаю тоже можно зарезать :)

Это надбавка к основному окладу она состоит из множества факторов, но я решил не париться этими факторами, а ограничиться, только указанием общей суммы. ;)

> wicked © (27.02.07 22:36) [33]

1. Согласен. Обсуждалось выше.
2. Согласен. Исправлю.
3. ИМХО субъективно. Только телефоны.
4. Number зарезервированное слово, пришлось обойтись его сокращением, а как еще обозначить номер паспорта?
есть такое правило - числовые типы нужно назначать только аттрибутам-значениям, а не аттрибутам свойствам
Если честно, не понял. Не могли бы сформулировать доступнее.
и зачем для поля job.deleted выделять аж 5 символов?
В Oracle нет boolean"а поэтому пишу False default или True, конечно можно и 0-1 и еще как, но так мне нагляднее.
5. Возможно будем ;)
6. Ответил выше в этом посте Knight"у
7. Тоже кажется субъективным.

Обязательно жду дальнейших замечаний. Серьёзно. Поскольку уже достаточно много прояснилось и завтра будет изменено.

Чтобы прояснилось ещё лучше... начни с самого начала... с ТЗ, а то окажется, что там ещё куча ограничений и перспектива борьбы за часть рынка 1С-ЗиК ;)

> AntiUser © (27.02.07 23:23) [36]

> 4. Number зарезервированное слово, пришлось обойтись его
> сокращением, а как еще обозначить номер паспорта?

имелось в виду то, зачем полю "номер паспорта" числовой тип?
я бы обьединил их с серией и сделал одним varchar-ом

> есть такое правило - числовые типы нужно назначать только
> аттрибутам-значениям, а не аттрибутам свойствам
> Если честно, не понял. Не могли бы сформулировать доступнее.

вкратце - "если над полем по правилам предметной области НЕ ПРЕДУСМАТРИВАЮТСЯ арифметические действия, то тип поля нужно делать символьным"
например:
поле "номер дома", "номер накладной" нужно делать символьным
поле "коэффициент надбавки", "процент скидки" - числовым

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

например, сделать его char(1) и проверять на "Y", "N"
либо, если есть в оракле enum-ы (наподобие enum-ов в mysql или перечислимых типов в паскале), то использовать их

Да нет ТЗ. Сижу без работы =( И чтобы не терять навыки и приобрести новые - пишу, но с оглядкой. Если получится удачно, то для малого предприятия (я пишу на основе последнего места работы) может и сгодится.

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

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