powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
11 сообщений из 11, страница 1 из 1
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
    #39913656
uaggster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Коллеги, приветствую!
Скажите, можно ли выбрать автоматически "достаточновместимый" тип по его текстовому представлению?

Есть примерно такая таблица:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
if OBJECT_ID('tempdb..#t') is not null
	drop table #t

Create table #t ([key] int, [type] sysname)

insert into #t
Values 
 (1, 'varchar(10)')
,(1, 'varchar(20)')
,(1, 'varchar(12)')
,(1, 'varchar(9)')
,(2, 'datetime2')
,(2, 'datetime')
,(2, 'date')
,(3, 'numeric(4,2)')
,(3, 'numeric(18,4)')
,(3, 'nimeric(11,5)')



[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.
 Select *, SQL_VARIANT_PROPERTY(t.n, 'BaseType'), SQL_VARIANT_PROPERTY(t.n, 'Precision') , SQL_VARIANT_PROPERTY(t.n, 'Scale')
from (
Select try_Cast('' as tinyint)
Union all 
Select try_Cast(Null as smallint)
) t(n)


И, собственно, смотреть, что получится.
Но как то уж очень громоздко получается.
Ни у кого нет более изящного решения?
...
Рейтинг: 0 / 0
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
    #39913673
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Данные практически любого типа можно уложить в varchar(max) и не париться.

Какая практическая цель твоей задачи?
...
Рейтинг: 0 / 0
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
    #39913690
uaggster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dimitry Sibiryakov
Данные практически любого типа можно уложить в varchar(max) и не париться.

Какая практическая цель твоей задачи?

Нет, это не подходит.

Это рефакторинг.
Имеется, много таблиц во множестве "однотипных" баз, причем они непосредственно недоступны для анализа (т.е. по sys.columns и иже с ними - лазить никто не даст).
Информацию можно получить в виде, примерно соответствующем см. выше.
Необходимо представить рекомендации по причесыванию всех под одну гребенку.
...
Рейтинг: 0 / 0
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
    #39913745
invm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
declare @t table ([key] int, [type] sysname);

insert into @t
Values 
 (1, 'varchar(10)')
,(1, 'varchar(20)')
,(1, 'varchar(12)')
,(1, 'varchar(9)')
,(2, 'datetime2')
,(2, 'datetime')
,(2, 'date')
,(3, 'numeric(4,2)')
,(3, 'numeric(18,4)')
,(3, 'numeric(11,5)');

select
 t.*, b.*
from
 @t t cross apply
 (select 'select cast(null as ' + t.[type] + ') as v;') a(query) cross apply
 sys.dm_exec_describe_first_result_set(a.query, null, 0) b;
...
Рейтинг: 0 / 0
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
    #39913823
uaggster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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.
declare @t table ([key] int, [type] sysname);

insert into @t
Values 
 (1, 'varchar(10)')
,(1, 'varchar(20)')
,(1, 'varchar(12)')
,(1, 'varchar(9)')
,(2, 'datetime2')
,(2, 'datetime')
,(2, 'date')
,(3, 'numeric(4,2)')
,(3, 'numeric(18,4)')
,(3, 'numeric(11,5)');

Select [key], system_type_name from (
Select tt.[key], stuff(q.txt, 1, len('Union All '), '')
from
	(Select distinct t.[key] from @t t) tt
	Cross apply (
	Select 
		'Union All Select cast('''' as ' +  t.[type] + ') '
		from @t t
		where t.[key] = tt.[key] 
		for xml path('')
		) q(txt)
	) a([key], txt)
 cross apply
 sys.dm_exec_describe_first_result_set(a.txt, null, 0) b;
...
Рейтинг: 0 / 0
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
    #39913836
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
uaggster
Имеется, много таблиц во множестве "однотипных" баз, причем они непосредственно недоступны для анализа (т.е. по sys.columns и иже с ними - лазить никто не даст).
Информацию можно получить в виде, примерно соответствующем см. выше.
Необходимо представить рекомендации по причесыванию всех под одну гребенку.


Это полная глупость.
Достаточность типа данных расчитывается из смысла, чтобы хватило лет на 5.

Если вас не пускают к базе, то можно дать только рекомендацию по приведению одних и тех же столбцов в разных таблицах к одному типу, да и то при условии соблюдения правил именования.
...
Рейтинг: 0 / 0
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
    #39913885
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На самом деле неизвестно - почему в одной базе таблица с таким же названием имеет такие параметры, а в другой базе - другие.

И насколько нужна избыточность. Я как-то писал процедуру, которая дает рекомендации по изменению типов колонок, но так толком и не воспользовался. Рефакторинг - дело тонкое.
...
Рейтинг: 0 / 0
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
    #39913997
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
uaggster
Это рефакторинг.
Имеется, много таблиц во множестве "однотипных" баз, причем они непосредственно недоступны для анализа (т.е. по sys.columns и иже с ними - лазить никто не даст).
Информацию можно получить в виде, примерно соответствующем см. выше.
Необходимо представить рекомендации по причесыванию всех под одну гребенку.
Супер, это рефакторинг, но данных о базах, объектах, никто не даст.
Видимо, им не нужно рефакторить, они просто любят смотреть на плачущих программистов.
uaggster
[type] - содержит валидное текстовое описание типа поля. Причем, оно, скажем так, не искажено злонамеренно. Т.е., для конкретного key не бывает цепочек varchar, varchar, int. Они все или "примерно varchar", или "примерно datetime", или "примерно int".

Можно ли для каждого key выбрать одну строку, которая содержала бы текстовое представление типа, который был бы минимально возможным контейнером для всех перечисленных типов для данного key?
ИМХО лучше подготовить данные, то есть распарсить [type], добавив новые поля, типа basetype, scale, precision

Так будет удобнее анализировать.
...
Рейтинг: 0 / 0
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
    #39914069
uaggster
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Народ, да это этап первичного осмотра объекта, т.с.
Там потом смотреть будут и глазами, и как угодно.
Просто небольшая задачка в процессе предварительной подготовки данных.
...
Рейтинг: 0 / 0
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
    #39914074
Фотография alexeyvg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
uaggster
Просто небольшая задачка в процессе предварительной подготовки данных.
Так распарсите [type], выделите из него компоненты, и анализировать будет намного проще.
...
Рейтинг: 0 / 0
Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
    #39914176
Владислав Колосов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В процессе рефакторинга не просто производится формальное сравнение, но и смысл содержимого. Например, целочисленные колонки могут быть заменены битовыми или float на numeric. Но это может повлечь за собой изменения в приложениях, работающих с базой. От "поверхностного рефакторинга" обычно не так много толка. Важно понять - с какой целью производятся изменения? Например, мы столкнулись с ошибкой переполнения при вставке или что-то ещё.
...
Рейтинг: 0 / 0
11 сообщений из 11, страница 1 из 1
Форумы / Microsoft SQL Server [игнор отключен] [закрыт для гостей] / Довольно идиотский вопрос по нахождению "достаточновместимого типа" автоматически
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]