DI является подмножеством IoC
Закончилось использованием решения аналогичного вопроса .
Тем не менее, спасибо! Мне нравится читать мнения всех об этих эзотерических областях дизайна баз данных.
А почему дополнительные шаги таблицы (processID JOIN, step INT) не подходят? Я уверен, что будет проще всего поддерживать / code.
SELECT process.name FROM process, steps WHERE process.id = steps.processID AND steps.step = 3;
Простите за мой SQL, но это было давно :)
РЕДАКТИРОВАТЬ: UNIQUE (processID, step)
было бы целесообразно.
Я бы использовал простой и канонический реляционный дизайн: CREATE TABLE range (process_id int, num_low int, num_hi int). Последние два столбца указывают диапазон. Независимый индекс по каждому столбцу. Для "особенного" Для бесконечных значений используются только максимальные значения или дополнительные логические столбцы.
Преимущества: простой поиск того, находится ли конкретный номер в диапазоне или пересекаются ли диапазоны. Простота обслуживания. Общая понятность и простота.
Недостатки: при изменении набора требуется некоторая логика, например проверка пересечения вновь вставленного или измененного диапазона. Могут потребоваться диапазоны сращивания.
Если вы не привязаны к SQL Server, Postgresql имеет отличную поддержку для такого рода вещей через массив . У них даже есть особое значение для бесконечности.
Если вы привязаны к SQL Server, лучше всего подойдет способ MitMaro.
create table setmember (setid int, setmemberid int)
create unique nonclustered index idx_setmember_idx1 on setmember (setid, setmemberid)
Позвольте мне предположить магическое число (-1 или 999999999) для «всех».
Это будет высокоэффективным как для запросов на основе набора, так и для вставки обновлений через некластеризованный индекс. Уникальность не требует повторения записей. Проблематично применять в качестве ограничения "все" или несколько членов набора,
Я не могу вспомнить правильную терминологию для этого, но правильный способ сделать это - создать таблицу, подобную приведенной ниже:
| id | table1_id | value |
--------------------------------
| 0 | 1 | 1 |
| 1 | 1 | 2 |
| 2 | 1 | 3 |
| 3 | 1 | 7 |
| 4 | 1 | 9 |
| 5 | 2 | 1 |
| 6 | 2 | 3 |
| ... | ... | ... |
Для каждого значения в таблице 1 вы добавляете необходимые значения в эту таблицу.
Для «все» вы можете создать столбец в таблице 1, который является флагом, который вы можете установить, если хотите все. (Я использую enum в MySql, но не уверен, существует ли это в SQL Server.)
Я не уверен, существует ли какой-то способ, специфичный для Sql Server, поскольку я использую в основном MySql.
The answer below to do a subtable (MitMaro) is the "standard" way.
IF you MUST put a set of numbers into one column or a table though the only way I can imagine is to use bitwise operations to store the set and you can use bitwise operations in you data queries to look for specific bits being set. Quick google searching indicates MSSql 2005 supports this but only up to 32-bit int, so if you steps pass 32 you will encounter issues.
All in all, the subtable is the most standard it would make for somewhat more understandable queries against the table(s). This is also the safest to support any future case where you would ned larger than 32 value maps.