Лучший способ сделать это, вероятно, , а не , чтобы сделать это - странно, что люди настаивают на хранении своих данных способом, который требует "гимнастики" SQL для извлечения значимой информации, когда гораздо проще способы достижения желаемого результата, если вы просто лучше структурируете свою схему: -)
правильный способ сделать это, на мой взгляд, это иметь следующую таблицу:
ID Col Val
-- --- ---
1 1 3
1 2 34
1 3 76
2 1 32
2 2 976
2 3 24
3 1 7
3 2 235
3 3 3
4 1 245
4 2 1
4 3 792
с ID/Col
в качестве первичного ключа (и, возможно, Col
в качестве дополнительного ключа, в зависимости от ваших потребностей). Тогда ваш запрос становится простым select min(val) from tbl
, и вы все равно можете обрабатывать отдельные «старые столбцы» отдельно, используя where col = 2
в других ваших запросах. Это также позволяет легко расширяться при увеличении количества «старых столбцов».
Это упрощает ваши запросы , поэтому . Общее правило, которое я обычно использую: если у вас когда-либо есть что-то, похожее на массив в строке базы данных, вы, вероятно, делаете что-то не так и должны подумать о реструктуризации данных.
Однако, если по какой-то причине вы не можете изменить эти столбцы, я бы предложил использовать триггеры вставки и обновления и добавить еще один столбец , для которого эти триггеры установлены на минимум. Col1/2/3
. Это переместит «стоимость» операции с выбора на обновление / вставку, к которому она относится - большинство таблиц базы данных в моем опыте читаются гораздо чаще, чем записываются, поэтому затраты на запись, как правило, со временем становятся более эффективными.
Другими словами, минимум для строки изменяется только при изменении одного из других столбцов, поэтому это , когда вам нужно его вычислять, а не каждый раз, когда вы выбираете (что теряется, если данные не не меняется). После этого вы получите таблицу типа:
ID Col1 Col2 Col3 MinVal
-- ---- ---- ---- ------
1 3 34 76 3
2 32 976 24 24
3 7 235 3 3
4 245 1 792 1
Любой другой вариант, который должен принимать решения во время select
, обычно является плохой идеей с точки зрения производительности, поскольку данные изменяются только при вставке / обновлении - добавление еще одного столбца занимает больше места в БД и будет немного медленнее для вставок и обновлений, но может быть намного быстрее для выбора - предпочтительный подход должен зависеть от ваших приоритетов, но, как указано, большинство таблиц читаются далеко чаще, чем они написано.