Оптимизация схемы для объединения в большой, но конечной группе таблиц

#sql #database #database-design

#sql #База данных #база данных-дизайн

Вопрос:

Здесь у меня есть некоторая гибкость, поэтому я ищу несколько советов, прежде чем все заблокировать. У меня также есть пара способов решения этой проблемы, но я ищу рекомендации по наиболее эффективному способу сделать это. Поскольку специфика моих типов данных немного неясна, я буду использовать более понятную объектную метафору.

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

  1. Каждой конкретной таблице animal присвоен уникальный файл, что-то вроде «диаметра рыла» для свиньи или «усов» для кошки. Существует также другое поле
  2. В таблице animal есть поле, отмечающее «Роль» животных.
  3. В клетке может быть несколько животных.
  4. Животные привязаны к клеткам с помощью ограничений FK. Конкретные таблицы Animal связаны с таблицей animal ограничениями FK.

    • Клетки
      • Животное
        • Cat
        • собака
        • Pig и т. Д

Основной задаваемый вопрос заключается в том, что находится в клетке? Мне также нужно иметь возможность как можно быстрее выполнять поиск по всем клеткам и получать всю информацию о животных, которые подпадают под роль «вкусных». Иногда свинья будет «вкусной», в других случаях это может быть кошка. В зависимости от типа «вкусного» животного мне нужно отобразить его конкретную информацию.

Какой наиболее эффективный дизайн схемы или оператор SQL для поиска этой информации?

В моей первой попытке этого были только клетки, а затем куча таблиц «SpecificAnimal». Это казалось плохой идеей, потому что мне пришлось бы выполнить объединение более чем 10 таблиц, чтобы выяснить, что находится в ячейке. Затем я переместил общие атрибуты в таблицу Animal, это позволило мне легко увидеть, какие животные находятся в клетке, хотя для получения всех данных по-прежнему требовался поиск по конкретным таблицам. Я рассматривал возможность сохранения определенных атрибутов в какой-либо форме строки CSV (но я еще не настолько отчаялся), конечно, я мог бы использовать EAV, но это также кажется неэффективным, поскольку на самом деле существует конечное число животных.

Я слишком беспокоюсь? Должен ли я просто стиснуть зубы и принять объединения в 10 таблицах? Просто беспокоюсь о производительности…. Любые идеи или шаблоны проектирования, которые могут быть рекомендованы. Страдаю от информационной перегрузки и насморка. Помогите, пожалуйста.

Комментарии:

1. Если у вас всего 10 таблиц, создайте базу данных и протестируйте ее, это единственный способ убедиться, что производительность будет приемлемой.

Ответ №1:

Действительно сложно ответить на вопросы «какая схема лучше», потому что они всегда предполагают компромиссы. Отчасти это означает, что для точного сопоставления одного дизайна с другим вам необходимо иметь измерения (например, скорости), на которых основывается ваше решение. (Вероятно, это не тот ответ, который вы искали).

Как бы то ни было, 10 объединений — это небольшое число, и в зависимости от количества животных и клеток в вашей системе вы можете никогда не заметить проблемы со скоростью. Кроме того, если действительно существует один «основной запрос», то вы можете использовать материализованные представления, чтобы хотя бы на этот запрос можно было быстро ответить.

Наконец, несколько всеобъемлющих советов: выбирайте чистую модель данных, пока у вас не будет жестких цифр, которые заставят вас «замутнить» дизайн.

Комментарии:

1. На самом деле, эти ответы полезны, 10 просто кажутся мне красным флагом. Я собираюсь попробовать промежуточный путь, который объединяет конкретных животных в виды. Клетка-> Животное-> млекопитающее. Это должно сократить количество объединений, сохраняя при этом необходимую мне непересекающуюся специализацию. Я хотел бы получить пару других мнений, но я бы принял этот ответ.