Comments 7
UFO just landed and posted this here
Это очень неоднозначное утверждение, все зависит от контекста.
По крайней мере, в данном случае на довольно приличных объемах данных уменьшения быстродействия по сравнению с аналогичными полями, содержащими int, замечено не было (несколько таблиц, в которых есть поля с перечислениями, по 300-500 тыс. строк, выборки с различными условиями where, group, join, update'ы, insert'ы.
По крайней мере, в данном случае на довольно приличных объемах данных уменьшения быстродействия по сравнению с аналогичными полями, содержащими int, замечено не было (несколько таблиц, в которых есть поля с перечислениями, по 300-500 тыс. строк, выборки с различными условиями where, group, join, update'ы, insert'ы.
Вся идея отдаёт бредом, на мой взгляд.
Enum в SQL-е — это просто доптаблица таблица, скажем, tEnum с двумя полями: ID и EnumMeaning, и подзапрос в основном Select-е.
Тогда запрос превращается в
Всё. Просто, эффективно, понятно, кросплатформенно.
Enum в SQL-е — это просто доптаблица таблица, скажем, tEnum с двумя полями: ID и EnumMeaning, и подзапрос в основном Select-е.
Тогда запрос превращается в
Select * from TargetTable where FieldOfInterest=(select id from tEnum where EnumMeaning='SomeStatus')
Всё. Просто, эффективно, понятно, кросплатформенно.
Просто, безусловно. Понятно. Но когда вам нужно будет удалить/изменить это перечисление, придется лопатить весь код вручную. А кто-то где-то уже написал 'SоmeStatus', например, с русской буквой 'о'. А все работало и продолжает работать, только вот неправильно.
А с кроссплатформенностью и без моих перечислений все не очень, или надо отринуть все фишки реализации помимо какого-нибудь SQL92
И да, поймите меня правильно, я ни в коем случае не агитирую за переделку всех таблиц вида ID — Name в enum'ы.
А с кроссплатформенностью и без моих перечислений все не очень, или надо отринуть все фишки реализации помимо какого-нибудь SQL92
И да, поймите меня правильно, я ни в коем случае не агитирую за переделку всех таблиц вида ID — Name в enum'ы.
(ошибся местом, это к этому комментарию)
В этом моменте душу мою терзают таки сомнения, что в итоге лучше = f(быстрее, удобнее, правильнее).
Enum'ы правильнее — если ты использовал его и собрался изменить, то всякие dependencies дадут тебе по рукам — сервер же ж не в курсе, как в свете этих изменений трактовать данные (есть не совсем понятный момент — если использовал только _внутри_ кода хранимой процедуры, то изменить можно, соответственно, если изменил только значение, например, было SomeStatus = 3, а стало = 4, то вуаля и все отлично, а если SomeStatus'а совсем не стало, то, по крайней мере, процедура не продолжит молча и неправильно работать, а при вызове упадет с внятным исключением)
Но изменение типа данных в куче таблиц… а там индексы, констрайнты… может оказаться очень даже не быстрее и не удобнее.
Наверное, это уже в сторону правильной разработки структуры БД :)
В этом моменте душу мою терзают таки сомнения, что в итоге лучше = f(быстрее, удобнее, правильнее).
Enum'ы правильнее — если ты использовал его и собрался изменить, то всякие dependencies дадут тебе по рукам — сервер же ж не в курсе, как в свете этих изменений трактовать данные (есть не совсем понятный момент — если использовал только _внутри_ кода хранимой процедуры, то изменить можно, соответственно, если изменил только значение, например, было SomeStatus = 3, а стало = 4, то вуаля и все отлично, а если SomeStatus'а совсем не стало, то, по крайней мере, процедура не продолжит молча и неправильно работать, а при вызове упадет с внятным исключением)
Но изменение типа данных в куче таблиц… а там индексы, констрайнты… может оказаться очень даже не быстрее и не удобнее.
Наверное, это уже в сторону правильной разработки структуры БД :)
Sign up to leave a comment.
«Real» enums for MS SQL Server