колонок будут происходить из маленького редко меняющегося набора, при будет много запросов, которые поммо всего прочего проверяют это поле на равенство. Есть несколько мыслей:
1. Делать по канонам нормальности, в значение запихнуть ID и сделать таблицу с инвариантами
Плюсы:
+ Удобно добавлять новые инварианты, каскадно удалять записи при удалении инварианта
Минусы:
- Джойниться к таблице (хоть и небольшой) на каждый запрос
- Не уверен, что можно будет нормально использовтаь индекс
2. Сделать энумератор
Плюсы:
+ Проще писать селекты с фильтрами
+ Нет джоина
+ Индексится
Минусы:
- Для добавления/удаления надо будет изворачиваться, сначала стирать по равенству этого аттрибута все сущности, а потом изменять энумератор
Какой подход посоветуете?
Я вот ничего не понял...
Table A |id: int|class_id: int fc table_b.id| Table B |id: int|classvalue: int| vs. Table A |id: int|classvalue: Enum(1,2,3)| Соответственно, запросы select A.id, B.classvalue from A join B on A.class_id == B.id where B.classvalue == X vs select A.id A.classvalue from A where A.classvalue == X
А просто проверить производительность на реальных данных, что запрещает? Ведь в теории оно одно, а на разных реальных данных может вести себя немного по разному...
Пока только проектирую, и есть представления о юзкейсах, но не о количестве данных
Ну, отмечайте, что нужно будет проверить оба варианта (благо обе реализации не сложные). Лучше так, чем выбрать что-то одно, а потом оно окажется тормознутым, а второй вариант из головы вылетит. (Такое часто бывает, когда решения кажутся очевидными и на самом деле являются элементарными, но в куче таких же других элементарных тупо теряются)
Обсуждают сегодня