Не могу решить, какую из структур выбрать...

Суть задачи:
- Есть каталог фирм
---- У каждой фирмы есть телефоны
---- У каждой фирмы есть ФИО сотрудников
---- У каждой фирмы есть... {N чего-то, адресов эл. почты, офисов и т.п.}
- Количество фирм от 500 000 до 3 000 000
- Таких данных как телефоны, ФИО и т.п. может быть от 0 до 10, ну макс. 15. В среднем, 2-4 телефона, 1-2 адреса эл. почты и 4-8 сотрудников.

Для чего понадобится:
Структура разрастаться не будет, например, не будет необходимости для каждого сотрудника назначать отдельный телефон или же для каждого офиса назначать сотрудников, телефоны и т.п.
Чтобы автоматически выбирать фирму и всё информацию о ней при входящем звонке, письме и т.п.
Будет относительно просто: звонит телефон, высветился номер 80991234567, пошёл запрос в БД, оттуда выбралась фирма, а также список сотрудников, номера телефонов, адреса эл. почты и т.п.
Если и будет дополнительная информация, то она будет завязана на фирму, а не на номер телефона или адрес эл. почты...

Не знаю, какую структуру выбрать для хранения - одну таблицу или несколько таблиц с перелинковкой....

Вариант 1:
firm: FirmId | Phones | FIOs | ...
Здесь FirmId - автоинкремент, а остальные столбцы содержат перечисление через запятую, т.е. {,3,7,9,1,3,} (без скобок), где цифры - это индексы в соответствующих таблицах с данными

phones : PhoneId | Value

Выборку делать по принципу явного равенства, например, phone.Value=$Phone

Вариант 2:
firm: FirmId | Phones | FIOs | ...
Здесь же не делать линки на другие таблицы, а прямо указывать телефоны, фио и т.п. через запятую, т.е. {,80951341960,80996719581,}

Выборку делать по принципу похожести, например, firm.phones LIKE "%,$Phone,%"

Вариант 3:
firm: FirmId

phones: PhoneId | Value

firm2phone: FirmId | PhoneId

Подскажите, что же целесообразней использовать?

Это сообщение отредактировал(а) fridkaratel - 20.5.2011, 08:33

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

таблица 1 - данные о фирме которые не изменны и постоянны
id - идентификатор
name - наименование
id_region - идентификатор региона (отдельная таблица)
id_city - идентификатор населённого пункта
adres - адрес (улица, корпус, дом...)
...... - дополнительные данные, например координаты GPS

таблица 2 - виды информации
id - идентификатор
name - имя
description - описание

таблица 3 - согласующая
id - идентификатор
id_firma - идентификатор фирмы
id_таблица2 - идентификатор информации из второй таблицы
options - необходимые значения

ну и как это работает...

есть фирма у которой есть два телефона, три мыла, 2 сотрудника, 2 адреса складов

Таблица 1

- 1, "Рога и Копыта", 68, 1, "Советская, д.4"...

Таблица 2
- 1, "telephon","телефон"
- 2, "email", "электронный почтовый адрес"
- 3, "jobs", "сотрудники фирмы"
- 4, "arhiv", "складские помещения"

Таблица 3
- 1, 1, 1, "9152345235"
- 2, 1, 1, "9152345235"
- 3, 1, 2, "[email protected]"
- 4, 1, 2, "[email protected]"
- 5, 1, 2, "[email protected]"
- 6, 1, 3, "Иванов#Иван#Иванович" 
- 7, 1, 3, "Иванов#Степан#Степанович"
- 8, 1, 4, "г.Энск, Ленина, 15"
- 9, 1, 4, "г.Энск, Советская, 44"

 - я использую в случае необходимости разделитель # так как он практически нигде не встречается в практике и удобно разделять данные если это нужно.

@Gold Dragon, думал над таким способом хранения - у меня в одном проекте также используется для контактов ;)

Здесь у меня N - это максимум, наверно, столбцов 6, т.е.: город, телефоны, почта, номера ICQ, сотрудники, офисы да и ... всё, вроде... Ну может ещё два каких будет...

Я тоже склонялся именно к явной перелинковке с отдельной таблицей...
Но смущает, что надо "наплодить" таблиц, а сильно ли это даст прирост в скорости поиска?

Да и к тому же, удалил из БД всего из одной таблицы всю информацию - и "хвосты" в других таблицах чистить не надо...
Ну а для поиска - повесить индекс на каждый из столбцов и делать выборку через LIKE "%,{value},%"...
Но опять же, не аукнется ли мне это потом? Будет ли LIKE работать быстрее, чем JOIN на 1 млн. записей и больше?

Это сообщение отредактировал(а) fridkaratel - 20.5.2011, 09:21

моя схема сделана для бесконечного количества различных параметров. В моём проекте их уже более 50 и постоянно добавляются, правда у меня структура чуть сложнее..

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

А чем отличается поиск от удаления?  просто находишь все связанные индексы и удаляешь... На счёт поиска я не уверен что у тебя будет быстрее искаться если ты всё засунешь в одну таблицу