Должен ли я поместить контактную информацию в отдельную таблицу? - PullRequest
0 голосов
/ 15 июля 2010

Я планирую базу данных, в которой есть несколько таблиц, которые содержат множество адресной информации, города, почтового индекса, адреса электронной почты, номера телефона, факса и т. Д. (Примерно на 11 столбцов), таблицыэто таблица организаций, содержащая (до) 2 адресов (юридические контакты и контакты, которые они должны фактически использовать), плюс каждый пользователь имеет одну и ту же информацию, связанную с ним.

Нам нужно будет выполнить некоторые геолокациии по этим адресам (как и по каждому адресу, находящемуся в X километрах от другого адреса).

У меня есть несколько вариантов, каждый со своей проблемой:

  1. Я мог бы поставить всеинформация внутри каждой таблицы, но это будет полезно для таблиц с очень большим количеством столбцов, которые у меня будут проблемы с индексацией, и если я изменю свой формат адреса, потребуется некоторое время, чтобы это исправить.
  2. Я мог быпоместить всю информацию в массив и сериализовать ее, затем сохранить сериализованную информацию в одном поле, та же проблема с предыдущим методом снемного меньше столбцов и намного меньше доступности через запросы mysql
  3. Я мог бы создать отдельную таблицу с адресной информацией и связать ее с другими таблицами либо

    1. , поместив столбец address_idв таблице пользователей и организаций
    2. размещение столбцов related_id и related_table в таблице адресов

    Это должно поддерживать порядок вещей, но может привести к непредвиденным проблемам с чрезмерным объединением или чем-то еще.

Лично я считаю, что решение 3.2 является лучшим, но я не слишком уверен в этом, поэтому я спрашиваю мнения.

1 Ответ

0 голосов
/ 15 июля 2010

Опция 2 определенно отсутствует, поскольку она добавит логику фильтрации в ваши коды, а не позволит СУБД обрабатывать их.

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

вариант 3 подходит при условии правильной индексации таблиц.

...