Как организовать структуру БД по сущности «Сотрудники»?

Question

[Станислав Шендаков]

Добрый день. Переписываем ERP. Возникли разногласия по структуре БД. Поделитесь пожалуйста ссылками на примеры структуры БД организации, для начала только по сотрудникам. Информация будет стандартная, адрес, паспорт, семья, дети, телефон, email и т.д. Заранее благодарен

Answer 1

[Евгений]

одна таблица - "сотрудники"
в ней колонки:
адрес, паспорт, семья, дети, телефон, email и т.д.
чо не так?

Comments

[RidgeA]

адресов, телефонов, детей и т. д. может быть много

[Евгений]

RidgeA, телефон1, телефон2, id-родлителя(для родителей null)

[RidgeA]

Евгений, ну так всю базу в одну таблицу можно положить... Это путь вникуда

[Евгений]

RidgeA,

ну так всю базу в одну таблицу можно положить...

иерархические таблицы? не?
ТС же не сказали для чего вам детей складировать и телефоны. для того что бы выйти на связь с сотрудником 2х телефонов более чем достаточно. Про детей мне вообще не ясно - узнать есть ли дети у сотрудника или нет - дак одно строковое поле с перечислением всех. Дети же не перемещаются между сотрудниками в общем случае.
Ну а так то если вам нужна архитектура ради архитектуры - то ваш ответ правильней да.

[Станислав Шендаков]

В предыдущем решении так и было, все в одну кучу. Особенно порадовал подход, когда данные из массива значений склеиваются в одну строчку с вертикальным слешем в качестве разделителя. Причем создатель всей этой хрени считает, что это нормальный подход. Сложность сейчас в том, что таблиц с разными сущностями будет несколько, х.з. сколько вообще. К примеру, сейчас рассматриваю такое решение. Есть таблица links и в ней поля id автоинкремент, первичный индекс, link_type_id ( int ) тип связи ( email, моб. тел, раб. тел, Telegram и.т.д ) data_digital ( int ) для телеф. номеров, data_alpha ( varchar ) для текстовых данных. Данные для связи могут быть и у пользователей, и у контрагентов и у родственников пользователей, т.е. завести user_id в таблице links не получится, неизвестно какой id там будет храниться. Завести поле link_id собственно в целевых таблицах тоже нельзя, так как контактов для связи может быть несколько. Для этого в каждой такой таблице я завел поле links типа JSON, где храню массив id из таблицы links типа [ 101, 115 ] и.т.д. Связь типа LEFT JOIN links on JSON_CONTAINS( users.links, CAST( links.id AS JSON ) ) работает, запросов таких будет немного, но я почти совсем не работал с JSON в MySQL. Как вам такой подход?

[Евгений]

Станислав Шендаков, интересно :) вы сначала поругали предыдущего разраба за то что он хранил строки с разделителями а сами храните строки с разделителями(json))))
Если у вас контакты и у людей и у организаций, тогда вам еще одну табличку запилить надо "contact_mapper" id - ид записи которая будет храниться у людей/орагнизаций и id_contact ид который можно засунуть в таблицу описанную вами. Но лучше контакты привязать строго к людям, а у контрагентов завести поле контактное лицо. всё сразу станет понятней.

[Станислав Шендаков]

А Вы не видите разницы? C JSON-данными MySQL работает ( ищет, модифицирует ) посредством встроенных функции. Не подскажете, как средствами MySQL найти что-либо в строке подобной следующей : "1|21.02.2012#10#23.02.2012|24.02.2012#10#29.02.2012"? В данной реализации это типовой случай, попадаются и такие: "0|02.03.2012#10#02.03.2012|16.03.2012#5#23.03.2012|16.03.2012#5#02.03.2012|16.03.2012#5#|16.03.2012#5#24.04.2012|17.04.2012#15#17.04.2012|17.04.2012#15#30.04.2012|17.04.2012#15#04.05.2012|17.04.2012#15#02.05.2012|30.04.2012#15#28.05.2012|04.05.2012#15#24.05.2012|21.05.2012#15#11.06.2012|13.06.2012#15#15.06.2012|15.06.2012#15#09.07.2012|05.07.2012#15#27.07.2012|05.07.2012#15#24.07.2012|19.07.2012#15#26.07.2012|31.07.2012#15#07.08.2012|17.08.2012#15#07.09.2012|03.09.2012#15#05.10.2012|09.10.2012#15#30.10.2012|25.10.2012#15#|13.11.2012#15#15.01.2013|13.11.2012#15#20.12.2012|17.12.2012#15#30.01.2013|25.01.2013#15#|28.01.2016#4#05.02.2016|11.02.2016#4#12.02.2016|02.03.2016#4#11.03.2016|20.04.2016#4#20.04.2016". Просто строка и строка в виде "[145, 39]" для MySQL ни хрена не одно и то-же. Может быть и лучше, как советуете Вы, я для этого здесь вопросы и задаю. Просто хочется максимум работы свалить на MySQL-сервер, чем после разгребать выборки вручную.

[Евгений]

Станислав Шендаков, извиняйте с MySQL не очень знаком

Answer 2

[RidgeA]

Можно так.
Есть таблица "Человек" - там ФИО, еще какие-то данные. Это будут и сотрудники, и члены семьи
Есть таблица с сотрудниками - там будет ссылка на запись в табилце человеков - это будут сотрудники.
Есть таблица со связью сотрудник - члены семьи, где в т. ч. будет указано отношение - супруг/супруга, ребенок и т.д.
По отдельной таблице на телефоны, email, адреса - у одного человека может быть их несколько - надо таблицу со связью между человеком и телефоном с указанием статуса телефона (основной, рабочий, мобильный) и т.д. (если это вообще надо)
С адресами можно чуть сложнее - если есть справочник городов/ улиц - тогда указывать связь с этим справочником. Можно, кончено, просто строкой.

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

Comments

[Станислав Шендаков]

Спасибо, примерно так я сейчас и предлагаю. И сотрудники, и их родственники в одной таблице, ссылки на степень родства в другой таблице, контакты для связи с описанием в третьей таблице ( тел. мобильный, рабочий, e-mail, WhatsApp и.т.д ), адрес с разбивкой на страну, город и улицу. Родственников может быть несколько, телефонов и e-mail тоже. Просто хотелось-бы посмотреть и сравнить с готовым решением.

Answer 3

[d-stream]

Есть еще ведь таблица "контрагенты"? (Ну или будет)

Так вот сотрудник - это контрагент + рюшечки касающиеся прав доступа и т.п. Притом временами контрагент-физик может стать еще и сотрудником и наоборот...

Comments

[Станислав Шендаков]

Обязательно будет. :)

[d-stream]

Станислав Шендаков, ну тогда - начинать с контрагента, а потом уже набабахивать к контрагенту рюшечки сотрудника