Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Миграция c Oracle на MS-SQL  [new]
iljy
Member

Откуда:
Сообщений: 8711
Konst_One
https://msdn.microsoft.com/ru-ru/library/ms187819(v=sql.120).aspx
вот этот раздел пусть внимательно почитает: Округление типа данных datetime до долей секунды

ЗЫ
поэтому для его задачи удобней datetime2(1)


Для его задачи удобнее datetime(2), потому что с datetime(1) можно изрядно нарваться. C datetime такой проблемы нет, но оно требует 8 байт вместо 6.

Выполните и посмотрите:
select CAST('20160101 16:41:23.251' as datetime2(1)),
	   CAST('20160101 16:41:23.349' as datetime2(1))
	   
select CAST('20160101 16:41:23.251' as datetime2(2)),
	   CAST('20160101 16:41:23.349' as datetime2(2))
	   
select CAST('20160101 16:41:23.251' as datetime),
	   CAST('20160101 16:41:23.349' as datetime)
14 апр 16, 14:50    [19056827]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
Konst_One
Member

Откуда:
Сообщений: 11538
datetime2 в любом случае нужен, тк с datetime куда больше проблем при округлении значений, вот сами смотрте:

select CAST('20160101 23:59:59.999'	as datetime), CAST('20160101 23:59:59.999'	as datetime2)  
14 апр 16, 14:55    [19056862]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
Алексей_12345
Member

Откуда:
Сообщений: 31
WarAnt
Алексей_12345,

..., но почему не так?
create table table1
(
  ddate  TIMESTAMP(1) not null,
  col_type NUMBER,
  col_value NUMBER
)


ddate - задуман как первичный ключ с типом TIMESTAMP(1). Тоесть группы сигналов пишутся с частотой 100 мс.

Под каждый сигнал (уникальный код) в таблице зарезервировано поле - Col+код (название поля)

Затем приходит набор сигналов (временная метка + массив из кода сигнала и их значений) Далее inertt в зависимости от кода сигналов в исходном массиве заполняются соответствующие поля в таблице.

Условный пример

Пришёл массив в 14.04.2016 13:45:16,7
Код 151 Значение 105,4
Код 387 Значение 22,46

В эту таблицу записывается

Insert into table1 (ddate, col151, col387)
values ('14.04.2016 13:45:16,7','105,4','22,46')
14 апр 16, 15:01    [19056892]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
iljy
Member

Откуда:
Сообщений: 8711
Konst_One
datetime2 в любом случае нужен, тк с datetime куда больше проблем при округлении значений, вот сами смотрте:

select CAST('20160101 23:59:59.999'	as datetime), CAST('20160101 23:59:59.999'	as datetime2)  


А в чем тут проблема-то? Типы разной точности округляются, очевидно, по разному. CAST('20160101 23:59:59.999' as datetime2(2)) тоже округлит вверх. ТС заявил точность 100мс, зачит его такое округление устраивает, зачем наносекунды хранить?
14 апр 16, 15:04    [19056914]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
Вообщем есть даже утилита от микрпософта для миграции с Оракла на Сиквел (для 2005 точно была) , можно взять результат ее работы за основу и полдпилить напильником
14 апр 16, 15:06    [19056934]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
Konst_One
Member

Откуда:
Сообщений: 11538
если у ТС вставка идёт конкретных значений, а не через getdate() в запросе на сервере, то вопросов нет, пусть саим себе точность обеспечивают на момент выполнения insert, тогда любой тип подойдет
14 апр 16, 15:07    [19056938]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
iljy
Member

Откуда:
Сообщений: 8711
Алексей_12345
Условный пример

Пришёл массив в 14.04.2016 13:45:16,7
Код 151 Значение 105,4
Код 387 Значение 22,46

В эту таблицу записывается

Insert into table1 (ddate, col151, col387)
values ('14.04.2016 13:45:16,7','105,4','22,46')


Вообще в таких случаях делают таблицу ddate, Code, Val. Хранение простыней должно иметь очень веские причины
14 апр 16, 15:07    [19056942]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
iljy
Member

Откуда:
Сообщений: 8711
Konst_One
если у ТС вставка идёт конкретных значений, а не через getdate() в запросе на сервере, то вопросов нет, пусть саим себе точность обеспечивают на момент выполнения insert, тогда любой тип подойдет


А если через GETDATE, то нельзя? Если запрос выполняется раз в 100мс?
14 апр 16, 15:08    [19056955]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
Glory
Member

Откуда:
Сообщений: 104760
Как бы между прочим
А почему структура и типы полей должны быть копией Ораклавских ?
Чтобы в очередной раз сказать - ну вот видите эмуляция Оракла на MS работает плохо ?
14 апр 16, 15:09    [19056956]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
Konst_One
Member

Откуда:
Сообщений: 11538
iljy
Konst_One
если у ТС вставка идёт конкретных значений, а не через getdate() в запросе на сервере, то вопросов нет, пусть саим себе точность обеспечивают на момент выполнения insert, тогда любой тип подойдет


А если через GETDATE, то нельзя? Если запрос выполняется раз в 100мс?


можно, только запросы иногда тормозят по не зависящим от них самих причинам, поэтому и время будет сбиваться, если не передавать константой, а через getdate()
14 апр 16, 15:16    [19056998]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
Алексей_12345
Member

Откуда:
Сообщений: 31
iljy
Алексей_12345
Условный пример

Пришёл массив в 14.04.2016 13:45:16,7
Код 151 Значение 105,4
Код 387 Значение 22,46

В эту таблицу записывается

Insert into table1 (ddate, col151, col387)
values ('14.04.2016 13:45:16,7','105,4','22,46')


Вообще в таких случаях делают таблицу ddate, Code, Val. Хранение простыней должно иметь очень веские причины


Старый вариант и был таким, он даже работает на старых версиях в других проектах (еле шевелится). Только и размер таблиц, и размер индексов, и выборка гораздо дольше.

Таблица терабайт+, индексы по несколько сотен метров и другие прелести.
14 апр 16, 15:17    [19057002]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
iljy
Member

Откуда:
Сообщений: 8711
Konst_One
iljy
пропущено...


А если через GETDATE, то нельзя? Если запрос выполняется раз в 100мс?


можно, только запросы иногда тормозят по не зависящим от них самих причинам, поэтому и время будет сбиваться, если не передавать константой, а через getdate()


Бывает, только тут не в типе дело.
14 апр 16, 15:17    [19057007]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
iljy
Member

Откуда:
Сообщений: 8711
Алексей_12345
iljy
пропущено...


Вообще в таких случаях делают таблицу ddate, Code, Val. Хранение простыней должно иметь очень веские причины


Старый вариант и был таким, он даже работает на старых версиях в других проектах (еле шевелится). Только и размер таблиц, и размер индексов, и выборка гораздо дольше.

Таблица терабайт+, индексы по несколько сотен метров и другие прелести.


Я не уверен, что причина в узких таблицах, ну да ладно. Если очень хочется простыню, то путь вам сказали: делайте SPARSE COLUMN и COLUMN SET
14 апр 16, 15:21    [19057027]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
Алексей_12345
Member

Откуда:
Сообщений: 31
Glory
Как бы между прочим
А почему структура и типы полей должны быть копией Ораклавских ?
Чтобы в очередной раз сказать - ну вот видите эмуляция Оракла на MS работает плохо ?


Причём тут это :)

1) Мне задали вопрос, перенести таблицу для хранения сигналов на ms-sql (тип "партянка", выше расписал что и как).
2) Меня смущает, что такая "партянка" может в MS-SQL не зашелится, и над будет делать чтот другое.
т.к.
2.1) Null в oracle не хранится, соответственно экономия места. Как с этим в MS?
2.2) Запросы из "партянки" выполняются быстро, т.к. oracle считывает конкретный столбец из таблицы. Как с этим в MS?

Мне для начало просто ответить, да не взлетит или над будет допилить и всё будет работать.
14 апр 16, 15:29    [19057068]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
Glory
Member

Откуда:
Сообщений: 104760
Алексей_12345
Причём тут это :)

При том, что вы именно пытаетесь эмулировать Оракл на MSSQL

Алексей_12345
2.1) Null в oracle не хранится, соответственно экономия места. Как с этим в MS?2.2) Запросы из "партянки" выполняются быстро, т.к. oracle считывает конкретный столбец из таблицы. Как с этим в MS?

Для того, чтобы в MS получить аналоги Оракла, нужно сделать больше, чем просто перенести таблицу один в один.
14 апр 16, 15:32    [19057084]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
WarAnt
Member

Откуда: Питер
Сообщений: 2421
Алексей_12345
WarAnt
Алексей_12345,

..., но почему не так?
create table table1
(
  ddate  TIMESTAMP(1) not null,
  col_type NUMBER,
  col_value NUMBER
)


ddate - задуман как первичный ключ с типом TIMESTAMP(1). Тоесть группы сигналов пишутся с частотой 100 мс.

Под каждый сигнал (уникальный код) в таблице зарезервировано поле - Col+код (название поля)

Затем приходит набор сигналов (временная метка + массив из кода сигнала и их значений) Далее inertt в зависимости от кода сигналов в исходном массиве заполняются соответствующие поля в таблице.

Условный пример

Пришёл массив в 14.04.2016 13:45:16,7
Код 151 Значение 105,4
Код 387 Значение 22,46

В эту таблицу записывается

Insert into table1 (ddate, col151, col387)
values ('14.04.2016 13:45:16,7','105,4','22,46')


и как это мешает структуре date_coltype?
Insert будет таким
Insert into table1 (ddate, coltype, colvalue)
values ('14.04.2016 13:45:16,7','151','22,46'), ('14.04.2016 13:45:16,7','387','22,46')

Зато не надо никаких доп индексов кроме кластерного по ddate, coltype и если пишется всего два поля из 900 размер таблицы будет меньше явно чем эта простыня.
Опять таки это всё справедливо для Скуля и не знаю как относится к Ораклу. Там ведь и курсоры, это хорошо:)
14 апр 16, 15:33    [19057091]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
Алексей_12345
Member

Откуда:
Сообщений: 31
WarAnt

и как это мешает структуре date_coltype?
Insert будет таким
Insert into table1 (ddate, coltype, colvalue)
values ('14.04.2016 13:45:16,7','151','22,46'), ('14.04.2016 13:45:16,7','387','22,46')

Зато не надо никаких доп индексов кроме кластерного по ddate, coltype и если пишется всего два поля из 900 размер таблицы будет меньше явно чем эта простыня.
Опять таки это всё справедливо для Скуля и не знаю как относится к Ораклу. Там ведь и курсоры, это хорошо:)


Я пример привёл чтоб много не писать из 2 сигналов.Их может быть и 2 в одной посылке, и 100, и 200.

Пришёл массив из 100 сигналов. В результате 100 строк в таблице типа (ddate, coltype, colvalue), причём появляются 100 значение с временем и 100 значений с кодом, которые физически должны храниться. Чего в "партянке" нет.

Для работы с такой таблицей нам будет нужен индекс по времени + код (ddate + coltype)
14 апр 16, 15:46    [19057150]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
Алексей_12345
Member

Откуда:
Сообщений: 31
Glory
Алексей_12345
Причём тут это :)

При том, что вы именно пытаетесь эмулировать Оракл на MSSQL

Алексей_12345
2.1) Null в oracle не хранится, соответственно экономия места. Как с этим в MS?2.2) Запросы из "партянки" выполняются быстро, т.к. oracle считывает конкретный столбец из таблицы. Как с этим в MS?

Для того, чтобы в MS получить аналоги Оракла, нужно сделать больше, чем просто перенести таблицу один в один.


Вот и мне нужно от вас, как от гуру MS подтверждение, что в лоб не перенести и надо привлекать спеца по MS-SQL, соответственно трудозатраты.

п.с. Если заказчик выбрал MS-SQL, пусть и закладывают спеца по MS-SQL. Проблемы то нет;)

п.с.с. мне просто как подтверждение своих слов расписать 2 пункта: про хранение null и про считывание столбцами. Что если я в лоб разверну таблицу на MS-SQL это может не взлететь.
14 апр 16, 15:55    [19057213]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
invm
Алексей_12345
NUMBER -A decimal number with up to 38 significant digits in the range of -(10**125) to +(10**125)
Что, реально нужен numeric(38)?
Если да, то вы не сможете создать в MS SQL таблицу с 900-ми столбцами такого типа.


Но оракуле всё numeric(38).
14 апр 16, 15:56    [19057222]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
Glory
Member

Откуда:
Сообщений: 104760
Алексей_12345
Вот и мне нужно от вас, как от гуру MS подтверждение, что в лоб не перенести и надо привлекать спеца по MS-SQL, соответственно трудозатраты.

Именно в лоб можно все перенести.
Но вы же спрашиваете о том, как вам получить функционал Оракла на MS.
14 апр 16, 15:59    [19057245]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
iljy
Member

Откуда:
Сообщений: 8711
Алексей_12345
Glory
пропущено...

При том, что вы именно пытаетесь эмулировать Оракл на MSSQL

пропущено...

Для того, чтобы в MS получить аналоги Оракла, нужно сделать больше, чем просто перенести таблицу один в один.


Вот и мне нужно от вас, как от гуру MS подтверждение, что в лоб не перенести и надо привлекать спеца по MS-SQL, соответственно трудозатраты.

п.с. Если заказчик выбрал MS-SQL, пусть и закладывают спеца по MS-SQL. Проблемы то нет;)

п.с.с. мне просто как подтверждение своих слов расписать 2 пункта: про хранение null и про считывание столбцами. Что если я в лоб разверну таблицу на MS-SQL это может не взлететь.



Вам расписали уже все. Есть варианты: узкая таблица либо разряженные столбцы. В обоих случаях значения NULL в таблице храниться не будут, но за счет некоторых потерь. Также можно рассмотреть использование столбца XML, там есть свои плюсы, но и свои минусы.
14 апр 16, 16:05    [19057302]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
Алексей_12345
Member

Откуда:
Сообщений: 31
Владислав Колосов
invm
пропущено...
Что, реально нужен numeric(38)?
Если да, то вы не сможете создать в MS SQL таблицу с 900-ми столбцами такого типа.


Но оракуле всё numeric(38).


Всяко можно настраивать. В реальности numeric(10,2) думаю хватит.



Glory
Алексей_12345
Вот и мне нужно от вас, как от гуру MS подтверждение, что в лоб не перенести и надо привлекать спеца по MS-SQL, соответственно трудозатраты.

Именно в лоб можно все перенести.
Но вы же спрашиваете о том, как вам получить функционал Оракла на MS.


Ну а как? я начальству заявлю, что всё перенесу, no prolems? вместо timetamp(1) тип datetime2(1) + под числа подобрать тип и всё, дело сделано?
Когда реальные данные пойдут, и в результате всё может встать колом? Я и хотю убедить, что требуется ms-sql спец...

п.с. Я просто для начала прошу ответить про null и выборку по столбцам? Просто как первоначальное обоснование, что трудозатрат будет больше, чем просто перенос в лоб.

п.с.с А то заявят, завтра ждём работающий результат.
14 апр 16, 16:15    [19057410]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
Glory
Member

Откуда:
Сообщений: 104760
Алексей_12345
я начальству заявлю, что всё перенесу, no prolems? в

Ставьте вопросы правильно.
Перенести данные <> мигрировать систему на новую платформу.

Алексей_12345
п.с. Я просто для начала прошу ответить про null и выборку по столбцам?

Какой вопрос то ? Хранит ли MSSQL все как Оракл ? Разумеется - нет
И ктстати ваши заявления про дефолтное сжатие этих значений и чтение по слобцам в Оракле по-моему не соответствуют действительности. В Оракле такой функционал тоже содается специалистом
14 апр 16, 16:24    [19057507]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
Алексей_12345
Member

Откуда:
Сообщений: 31
Glory
...
Хранит ли MSSQL все как Оракл ? Разумеется - нет
...


Нашёл годовалой давности тестовые данные, на основании которых и появилась решение "партянка", и которое сейчас хотят на MS-SQL перенести.

create table SIGHIST_TEST
(
  date_reg   TIMESTAMP(1) not null,
  sig1_val   NUMBER,
  sig2_val   NUMBER,
   ……
  sig499_val NUMBER,
  sig500_val NUMBER
)


Скриптом 450 сигналов пишутся каждые 0,2 сек, 50 сигналов раз в минуту(соответственно в остальных случаях null). Период - год.
Значения рандомно от 0 до XXX.YY. Итого - 157 680 000 строк в таблице

Вес таблицы-"партянки" получился 435 Гиг (реал. значения 332 Гиг + 100 Гиг служебная информация (доп. информации о длине строк, размещении строк в блоках, заголовки блоков, карта экстентов в таблспейсе и т.п.)) + индекс по дате timestamp(1) - 3,3 Гб

Аналогичные данные на узкой таблице (date, code, val)- только чистые значения (без служ. информации и не считая индекса) составили 1.6 Тб.

Итого:
Вечером начну с MS-SQL разбираться, качать и устанавливать базу. Аналогично попробую заполнить, чтоб окончательный ответ уж получить.

Для начала аналогичную таблицу для чистоты создам.
date_reg вместо timestamp(1) datetime2(1)
вместо number float
и заполню её аналогичным набором данных за один месяц, итоговые цифры на 12 умножу.
14 апр 16, 17:33    [19057977]     Ответить | Цитировать Сообщить модератору
 Re: Миграция c Oracle на MS-SQL  [new]
Алексей_12345
Member

Откуда:
Сообщений: 31
Glory
Какой вопрос то ?



Будет это решение работать на MS или нет?
Которое, как я понял, состоит из 2 основных подвопросов - Способ хранения null и выборка столбцом. Судя по тому, что нет прямого ответа, придётся самому разбираться.
14 апр 16, 17:42    [19058022]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить