У меня есть модель, у которой уже есть несколько десятков столбцов, которые будут заполняться большую часть времени. Теперь мне нужно добавлять поля, которые могут быть разными каждый раз.Записи с дополнительными свойствами: разреженная таблица или EAV?
Какой лучший подход? Мне не нравится шаблон EAV. Мне также не нравится идея иметь разреженный стол, особенно учитывая, как эти дополнительные свойства могут быть разными.
Пример:
WorkOrder:
PK id
FK assigned_to
FK contractor
DATE expected_completion
DATE actual_completion
... (many more)
Теперь я хочу, чтобы добавить такие свойства, как:
ep_1 (extra_property)
ep_2
ep_3
ep_4
... (many more)
Эти дополнительные свойства могут быть сильно отличается от записи к записи, и большую часть времени будет ограничено их число, но никаких гарантий нет.
Think записей, как:
id | assigned_to | contractor | ... | ep_1 | ep_2 | ep_3 | ... | ep_n
1 | 2 | 3 | ... | XYZ | NULL | NULL | ... | 23
2 | 3 | 5 | ... | NULL | 1 | NULL | ... | NULL
3 | 2 | 1 | ... | NULL | 0 | NULL | ... | NULL
4 | 4 | 1 | ... | XYZ | NUL | NULL | ... | 45
Я хочу, чтобы иметь возможность перечислить, фильтровать и запись поиска, как если бы эти дополнительные свойства были на самом деле столбцы, например: я должен быть в состоянии делать запросы как SELECT fields FROM table WHERE ep_n > 20 и SELECT fields FROM table WHERE ep_1='ABC'
Какое оптимальное решение?
Не зная всех свойств, которые вы ожидаете встретить, сложно сделать предложения. –
@OMG Это сделало бы вопрос слишком локализованным. Просто подумайте о них как о данных. Я должен иметь возможность делать запросы типа 'SELECT fields FROM table WHERE ep_n> 20' или' SELECT fields FROM table WHERE ep_1 = 'ABC'' – Aillyn
Я не согласен с вашими ожиданиями - это дизайн, который поможет вам угол, когда альтернативой является правильное моделирование таблиц и включение необходимых объединений. Не могу смоделировать эти таблицы, не зная, что они ... –