Мы работаем над картографическим приложением, которое использует Google Maps API для отображения точек на карте. Все точки в настоящее время выбираются из базы данных MySQL (содержит около 5 миллионов записей). В настоящее время все объекты хранятся в отдельных таблицах с атрибутами, представляющими отдельные свойства.
Это создает следующие проблемы:
Каждый раз, когда появляется новое свойство, мы должны вносить изменения в базу данных, код приложения и интерфейс. Это все хорошо, но некоторые свойства должны быть добавлены для всех сущностей, так что это становится кошмаром для просмотра более 50 различных таблиц и добавления новых свойств.
Нет способа найти все объекты, которые разделяют данное свойство, например, невозможно найти все школы / колледжи или университеты, в которых есть отдел географии (без запроса школ, университетов и колледжей по отдельности).
Удаление имущества одинаково болезненно.
Нет стандартов для определения свойств в отдельных таблицах. То же свойство может существовать с другим именем или типом данных в другой таблице.
Невозможно связать или сгруппировать точки на основе их свойств (как-то связанных с пунктом 2).
Мы думаем перестроить всю базу данных, но без помощи DBA и отсутствия профессионального опыта проектирования DB мы действительно боремся.
Другая проблема, с которой мы сталкиваемся в новом дизайне, заключается в том, что между сущностями существует множество общих атрибутов / свойств.
Например:
Сущность под названием " University " имеет более 100 атрибутов. Другие организации (например, больницы, банки и т. Д.) Имеют довольно много общих черт с университетами, например, банкоматы, парковка, кафетерий и т. Д.
Мы действительно не хотим иметь свойства в отдельной таблице [и затем связывать их обратно с сущностями с внешними ключами], поскольку это потребует добавления / удаления вручную. Также обобщение свойств приведет к группам, содержащим более 50 атрибутов. Не все записи (т.е. объекты) требуют этих свойств.
Итак, помня об этом, вот что мы думаем о новом дизайне :
Для каждой сущности есть отдельные таблицы, содержащие основную информацию, например, идентификатор, имя и т. д. и т. д.
Имеют 2 таблицы атрибут типа и атрибут для хранения информации о свойствах.
Свяжите каждую сущность (или таблицу, если хотите) с атрибутом , используя отношение «многие ко многим».
Хранить адреса в другой таблице, называемой адреса связывать сущности через внешние ключи.
Мы считаем, что это позволит нам быть более гибкими при добавлении, удалении или запросе атрибутов.
Однако этот дизайн приведет к увеличению числа объединений при извлечении данных, например, для отображения всех « атрибутов » для данного университета. У нас может быть запрос с 20+ объединениями для извлечения всех связанных атрибутов один ряд.
Нам крайне необходимо знать некоторые мнения или возможные недостатки в этом подходе к проектированию.
Спасибо за ваше время.