Правила проектирования баз данных для программиста

Question

Мы работаем над приложением сопоставления, которое использует API Карт Google для отображения точек на карте. В настоящее время все баллы извлекаются из базы данных MySQL (хранятся несколько записей 5M +). В настоящее время все объекты хранятся в отдельных таблицах с атрибутами, представляющими отдельные свойства.

Это представляет следующие проблемы:

1. Каждый раз, когда есть новое свойство, которое мы должны внести изменения в базу данных, код приложения и передний конец. Все это прекрасно, но некоторые свойства должны быть добавлены для всех объектов, так что это становится кошмаром, чтобы пройти через 50 разных таблиц и добавить новые свойства.

2. Невозможно найти все объекты, которые делят какое-либо данное свойство, например. никоим образом не найти всех школ/колледжей или университетов, имеющих отдел географии (без учета школ, университетов и колледжей отдельно).

3. Удаление имущества одинаково болезненно.

4. Нет стандартов для определения свойств в отдельных таблицах. Такое же свойство может существовать с другим именем или типом данных в другой таблице.

5. Невозможно связать или сгруппировать точки в зависимости от их свойств (как-то связанных с пунктом 2).

Мы собираемся переделать всю базу данных, но без помощи DBA и отсутствия профессионального опыта проектирования БД, который мы действительно боремся.

Еще одна проблема, с которой мы сталкиваемся с новым дизайном, заключается в том, что между объектами существует множество общих атрибутов/свойств.

Например:

Предприятие называется "университет" имеет более 100 атрибутов. Другие организации (например, больницы, банки и т. Д.) Имеют довольно много атрибутов в университетах, например, в машинах, стоянках, кафетериях и т. Д.

Мы не хотим иметь свойства в отдельной таблице [а затем связывание их с объектами w/foreign keys], поскольку это потребует от нас добавления/удаления вручную. Также обобщающие свойства получат группы, содержащие более 50 атрибутов. Не все записи (т. Е. Объекты) требуют этих свойств.

Так с сохранением, что в виду то, что мы думаем о новом дизайне:

• имеют отдельные таблицы для каждого объекта, содержащие некоторую базовую информацию, например, Идентификатор, имя и т.д. и т.п.

• Есть 2 таблицы типа атрибута и атрибута для хранения свойств информации.

• Link каждый объект (или таблицы, если вы хотите), чтобы атрибут используя многие-ко-многим.

• Адрес магазина в другой таблице, называемый адресов объектов связи через внешние ключи.

Мы считаем, что это позволит нам быть более гибкими при добавлении, удалении или запросе атрибутов.

Этот проект, однако, приведет к увеличению числа объединений при выборке данных egto показать все «атрибуты» для данного университета мы могли бы иметь запрос с 20+ присоединяется, чтобы извлечь все атрибуты, связанные в одной строке ,

Нам отчаянно нужно знать некоторые мнения или возможные недостатки в этом дизайнерском подходе.

Спасибо за ваше время.

Answer 1

При попытке обобщить свой вопрос без конкретных примеров трудно покритиковать ваш подход. Если вы хотите получить более подробный анализ, попробуйте взбить ER diagram.

Если ваша модель данных изменяется настолько, что вы постоянно добавляете/удаляете свойства, и многие из этих свойств перекрываются, вам может быть лучше использовать EAV.

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

Ex) У моего Db есть Щенки, Котята и Моржи с атрибутом hasFur и furColor. Удалите эти атрибуты из трех таблиц и создайте таблицу FurryAnimal, которая связывается с каждой из них.

Конечно, самый простой ответ - не трогать модель данных. Вместо этого создайте Views на базовых таблицах, которые вы можете использовать для адреса (5), (4) и (2)

Answer 2

1 не может быть проблемой. Существует одно место, где определены ваши объекты. Все остальное генерируется/получается из этого. Просто отредактируйте свой код, пока это не так.

2 решается путем использования метамодели, где вы описываете, какие свойства есть. Вероятно, это тоже необходимо для 1.

Возможно, вы захотите, чтобы это полностью устранить проблему, программируя это в Smalltalk с помощью Seaside на объектно-ориентированной базе данных Gemstone. Тогда вы можете просто создавать объекты с коллекциями и не нуждаться в стольких объединениях.