|
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
|
|||
---|---|---|---|
#18+
Коллеги, приветствую! Скажите, можно ли выбрать автоматически "достаточновместимый" тип по его текстовому представлению? Есть примерно такая таблица: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
[type] - содержит валидное текстовое описание типа поля. Причем, оно, скажем так, не искажено злонамеренно. Т.е., для конкретного key не бывает цепочек varchar, varchar, int. Они все или "примерно varchar", или "примерно datetime", или "примерно int". Можно ли для каждого key выбрать одну строку, которая содержала бы текстовое представление типа, который был бы минимально возможным контейнером для всех перечисленных типов для данного key? Должно получиться, как мне кажется, следующее (. в нумерик - потому что не знаю, как в теге csv заэкранировать запятую :-) ) 1 'varchar(20)'2 'datetime2'3 'numeric(19.5)' Годится любое решение, в т.ч. и с помощью динамического sql. Есть мысль для каждого key генерировать динамически запрос вида: Код: sql 1. 2. 3. 4. 5. 6.
И, собственно, смотреть, что получится. Но как то уж очень громоздко получается. Ни у кого нет более изящного решения? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2020, 14:03 |
|
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
|
|||
---|---|---|---|
#18+
Данные практически любого типа можно уложить в varchar(max) и не париться. Какая практическая цель твоей задачи? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2020, 14:36 |
|
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Данные практически любого типа можно уложить в varchar(max) и не париться. Какая практическая цель твоей задачи? Нет, это не подходит. Это рефакторинг. Имеется, много таблиц во множестве "однотипных" баз, причем они непосредственно недоступны для анализа (т.е. по sys.columns и иже с ними - лазить никто не даст). Информацию можно получить в виде, примерно соответствующем см. выше. Необходимо представить рекомендации по причесыванию всех под одну гребенку. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2020, 14:45 |
|
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
|
|||
---|---|---|---|
#18+
Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2020, 15:31 |
|
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
|
|||
---|---|---|---|
#18+
invm, немного не так :-), но за наводку - большое спасибо!!! Кому интересно: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29.
... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2020, 16:50 |
|
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
|
|||
---|---|---|---|
#18+
uaggster Имеется, много таблиц во множестве "однотипных" баз, причем они непосредственно недоступны для анализа (т.е. по sys.columns и иже с ними - лазить никто не даст). Информацию можно получить в виде, примерно соответствующем см. выше. Необходимо представить рекомендации по причесыванию всех под одну гребенку. Это полная глупость. Достаточность типа данных расчитывается из смысла, чтобы хватило лет на 5. Если вас не пускают к базе, то можно дать только рекомендацию по приведению одних и тех же столбцов в разных таблицах к одному типу, да и то при условии соблюдения правил именования. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2020, 17:23 |
|
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
|
|||
---|---|---|---|
#18+
На самом деле неизвестно - почему в одной базе таблица с таким же названием имеет такие параметры, а в другой базе - другие. И насколько нужна избыточность. Я как-то писал процедуру, которая дает рекомендации по изменению типов колонок, но так толком и не воспользовался. Рефакторинг - дело тонкое. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2020, 18:16 |
|
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
|
|||
---|---|---|---|
#18+
uaggster Это рефакторинг. Имеется, много таблиц во множестве "однотипных" баз, причем они непосредственно недоступны для анализа (т.е. по sys.columns и иже с ними - лазить никто не даст). Информацию можно получить в виде, примерно соответствующем см. выше. Необходимо представить рекомендации по причесыванию всех под одну гребенку. Видимо, им не нужно рефакторить, они просто любят смотреть на плачущих программистов. uaggster [type] - содержит валидное текстовое описание типа поля. Причем, оно, скажем так, не искажено злонамеренно. Т.е., для конкретного key не бывает цепочек varchar, varchar, int. Они все или "примерно varchar", или "примерно datetime", или "примерно int". Можно ли для каждого key выбрать одну строку, которая содержала бы текстовое представление типа, который был бы минимально возможным контейнером для всех перечисленных типов для данного key? Так будет удобнее анализировать. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.01.2020, 22:03 |
|
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
|
|||
---|---|---|---|
#18+
Народ, да это этап первичного осмотра объекта, т.с. Там потом смотреть будут и глазами, и как угодно. Просто небольшая задачка в процессе предварительной подготовки данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2020, 07:50 |
|
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
|
|||
---|---|---|---|
#18+
uaggster Просто небольшая задачка в процессе предварительной подготовки данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2020, 08:01 |
|
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
|
|||
---|---|---|---|
#18+
В процессе рефакторинга не просто производится формальное сравнение, но и смысл содержимого. Например, целочисленные колонки могут быть заменены битовыми или float на numeric. Но это может повлечь за собой изменения в приложениях, работающих с базой. От "поверхностного рефакторинга" обычно не так много толка. Важно понять - с какой целью производятся изменения? Например, мы столкнулись с ошибкой переполнения при вставке или что-то ещё. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.01.2020, 11:27 |
|
|
start [/forum/topic.php?fid=46&msg=39914069&tid=1686654]: |
0ms |
get settings: |
12ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
36ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
others: | 316ms |
total: | 453ms |
0 / 0 |