Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > MySQL > Подскажите, какую из двух структур БД выбрать

Автор: fridkaratel 20.5.2011, 08:20

Не могу решить, какую из структур выбрать... Суть задачи: - Есть каталог фирм ---- У каждой фирмы есть телефоны ---- У каждой фирмы есть ФИО сотрудников ---- У каждой фирмы есть... {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 Подскажите, что же целесообразней использовать?

Автор: Gold Dragon 20.5.2011, 08:46

у меня есть проект с чем то похожим.. вдруг покажется оптимальное таблица 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, "mail@mail.ru" - 4, 1, 2, "info@mail.ru" - 5, 1, 2, "adm@mail.ru" - 6, 1, 3, "Иванов#Иван#Иванович"  - 7, 1, 3, "Иванов#Степан#Степанович" - 8, 1, 4, "г.Энск, Ленина, 15" - 9, 1, 4, "г.Энск, Советская, 44"  - я использую в случае необходимости разделитель # так как он практически нигде не встречается в практике и удобно разделять данные если это нужно.

Автор: fridkaratel 20.5.2011, 09:12

@Gold Dragon, думал над таким способом хранения - у меня в одном проекте также используется для контактов ;) Здесь у меня N - это максимум, наверно, столбцов 6, т.е.: город, телефоны, почта, номера ICQ, сотрудники, офисы да и ... всё, вроде... Ну может ещё два каких будет... Я тоже склонялся именно к явной перелинковке с отдельной таблицей... Но смущает, что надо "наплодить" таблиц, а сильно ли это даст прирост в скорости поиска? Да и к тому же, удалил из БД всего из одной таблицы всю информацию - и "хвосты" в других таблицах чистить не надо... Ну а для поиска - повесить индекс на каждый из столбцов и делать выборку через LIKE "%,{value},%"... Но опять же, не аукнется ли мне это потом? Будет ли LIKE работать быстрее, чем JOIN на 1 млн. записей и больше?

Автор: Gold Dragon 20.5.2011, 09:38

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)