Доброго времени суток. В ходе разработке крупного проекта понадобилась сделать систему зависимостей. Я помозговав немного сотворил такое чудо. Суть в том, что есть таблица зависимостей в которой указан ID постройки (уровень постройки - не используется) тип - если там 1 то зависимость от другой постройки если 2 то от еще какой то сущности item_id - id той сущности level - уровень той сущности у пользователя. Вопрос собственно в том чтоб каким то образом минимизировать запросы к БД и сделать систему проверки зависимостей максимально простой. Ибо получается что мне нужно выбрать с таблицы зависимости где id постройки равен к примеру 11, потом перебрать этот массив, через swith по типу потянуть либо Buildings_Data либо еще какую то таблицу где id постройки равен item_id, а если в одной зависимости 5 параметров и все к разным таблицам, о как то не камельфо по скорости. PS. Если есть какие то предложения по переработке структуры системы с зависимостями, я буду рад.
Задачи по оптимизации баз данных начинаются с глубочайшего изучения системы. Не пары таблиц, а всей БД и всей зависимой логики. Вполне может оказаться, что какие-то данные вообще выгодно хранить не в базе данных, а где-то в другом месте или хранить в БД, но в сериализованном виде. А быть может нужно выделить общие данные (с частичным дублированием) в отдельную таблицу таким образом, чтобы "item_id" всегда ссылался на одну конкретную таблицу.
непонятна предметная область, например абсолютно неясно что такое "зависимость" и тем более что такое "уровень сущности у пользователя". чисто формально, вызывает сомнение, что ты собираешся перебирать какие-то массивы и решать к какой таблице обратиться на основании каких-то "переключателей". это заведомо провальная стратегия. Добавлено спустя 1 минуту 41 секунду: sql создан для обработки множеств — вот его и нагружай этими множествами. для каждой связи между сущностями заведи по отдельному полю, либо даже по ссылочной таблице, если это связь много-ко-многим.
Если выборку и БД нужно гнать в цикле через свитчи, значит выборка была сделана заведомо неправильно. Вся суть SQL в том, чтобы сказать базе, что те надо и забрать у нее что ты хош. В уже готовом, без лишнего мусора и, даже, отсортированном виде.