Vmelnikoff
@Vmelnikoff
PHP разработчик

Как лучше организовать схемы таблиц БД (контакты-персоны-компании)?

Думаю как лучше организовать таблицы.
Суть: Хранилище сущностей, которые могут быть персонами или компаниями, некоторые их которых оказывают строительные услуги, некоторые юридические. У каждой сущности может быть 0 или несколько телефонов, мейлов, и других средств связи. Кол-во около 500 000 записей.
Нужно организовать вывод персон, компаний, поиск, по всем полям, проверка и объединение дубликатов по mail/phone и т.д. поиск то телефонам/мейлам на вывод и компаний и персон, по компаниям возможность увидеть связанных с ней персон. Синхронизацию с другой базой - если у связь этого телефона/мейла и т.д. is_builder = 0, а у них is_builder = 1, то при синхронизации у нас меняем на is_builder = 1, не знаю куда лучше это поле к персоне или хранилищу

Планы по организации таблиц
Таблица contacts
  • id
  • type - enum тип company/person
  • для person свои уникальные поля - full_name, last_name,...passport...birthday......
  • для company свои уникальные поля - company_name, ОПФ, inn, kpp, юр.адрес
  • статусы для обоих - is_builder/is_lawer
  • created_at
  • updated_at


Таблица store_contacts - храним в одном месте мейлы, телефоны, урлы, скайпы и т.д., разделяя по типам
  • id
  • contact_id
  • type - enum тип мейлы, телефоны, урлы, скайпы и т.д
  • value
  • is_main


Теперь какие вижу проблемы
1. Две таблицы с одной стороны более быстрый поиск, с другой много лишнего, наверно проще разделить на две таблицы: persons и companies у каждой свои уникальные поля, а в store_contacts, тогда как быть?
Заменить один столбец contact_id на 2 столбца: person_id и company_id, получиться немного мусора лишний столбец, для каждой строки. Плюс только при разделении как понимаю я могу получить связь персоны с компанией, которая нужна.
2. Какие обычно английские названия столбцов используются для реквизитов российских компаний?
3. У телефонов и мейлов также нужны особенности по телефонам тип: мобильный, рабочий и т.д., по мейлам статусы - подтвержден, не потвержден, разрешение на разные виды подписок и т.д.
Как здесь лучше быть, чтобы не потерять в скорости обработки - выводить специфику в отдельные таблицы и делать связи с store_contacts?
4. Что делать с номерами телефонов сейчас в одном поле phone - 79991112233, стоит ли для ускорения добавить второй столбец с отформатированным форматом к примеру phone_formated - +7 (999) 111-22-33, т.е. поступиться размером БД, для снижения затрат на представление, при выводе 100-1000 телефонов?
5. Что лучше делать с дублирующими мейлами Яндекса? @ya.ru yandex.ru
Как вариант думаю в базе все приводить к @ya.ru, т.е. во всех формах поставить условие автозамены.
  • Вопрос задан
  • 190 просмотров
Решения вопроса 1
Vmelnikoff
@Vmelnikoff Автор вопроса
PHP разработчик
Вопрос с дублирующими мейлами Яндекса закрываем - останавливаемся на проверке и приведению к ya.ru при сохранении в базу.

С остальным особенно с разделением сущностей, пока остается не понятным.
В том числе:
Нужно организовать вывод персон, компаний, поиск, по всем полям, проверка и объединение дубликатов по mail/phone и т.д. поиск то телефонам/мейлам на вывод и компаний и персон, по компаниям возможность увидеть связанных с ней персон. компаний
Синхронизацию с другой базой - если у связь этого телефона/мейла и т.д. is_builder = 0, а у них is_builder = 1, то при синхронизации у нас меняем на is_builder = 1, не знаю куда лучше это поле к персоне или хранилищу
Итак вкратце, как все же лучше проектировать базу

Таблица - contact
Таблицы - contact_person и contact_company
Таблицы - contact_phone, contact_email и contact_social

Я правильно понял, что для выполнения этих задач делать связку где главная contact, а от нее идут к примеру contact_person и contact_phone

--- Добавлено 24/01/2018 ---
В общем для себя решил так сделать, делюсь может кому поможет
Таблица - contact для связки
В ней тип (person/company) и его ID
C другой стороны тип(phone/email/social) и его ID
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
@BorisKorobkov Куратор тега MySQL
Web developer
1. Сущности принято именовать в единственном числе.
В contact только общие поля. Дополнительные в contact_person и contact_company (PK является FK).

2. Транслитом: inn, kpp, okpo, opf

3. Мобильный/рабочий - разными store_contact.type

4. Телефоны все приводить к единому формату E.164 перед вставкой в БД

5. Email все приводить к единому формату (в нижнем регистре и, возможно, с заменой ya.ru) перед вставкой в БД
Ответ написан
@vism
Все разделять, если проект будет расти и меняться.
сущности человека и компании обрастут специфичными полями.
контакты человека и компании обрастут специфичными полями.

Плюс получите большие потери времени, чтоб закодить эту универсальность
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы