Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10   вперед  Ctrl      все
 Re: MS SQL Server FOREVER!?!?!  [new]
Crip
Member

Откуда:
Сообщений: 2490
не серверное это дело календари писать Это скорее из области задачек на сообразительность , чем показатель превосходства СУБД.
3 апр 03, 16:16    [164060]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
И откуда он его выдает?

Ты бы запрос-то привел - может он из такой же таблички select * from Kalendar и делается?

3 апр 03, 16:16    [164062]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
DimaR
Member

Откуда:
Сообщений: 1570
Ничего левого все стандартное, поизголяться можно еще каких красивостей добавить, тут в принципе ничего особенно Оракловского неиспользуеться.
SELECT

TO_CHAR(DAY,'MM.YYYY') "Месяц",
MAX(DECODE (day_of_week, 'MON', dd, NULL)) "ПН",
MAX(DECODE (day_of_week, 'TUE', dd, NULL)) "ВТ",
MAX(DECODE (day_of_week, 'WED', dd, NULL)) "СР",
MAX(DECODE (day_of_week, 'THU', dd, NULL)) "ЧТ",
MAX(DECODE (day_of_week, 'FRI', dd, NULL)) "ПТ",
MAX(DECODE (day_of_week, 'SAT', dd, NULL)) "СБ",
MAX(DECODE (day_of_week, 'SUN', dd, NULL)) "ВС"
FROM (
SELECT dd.N+1 dd,
DAY,
TO_CHAR (MM_DAYS.DAY + dd.N,
'DY', 'NLS_DATE_LANGUAGE=AMERICAN') AS day_of_week,
DECODE ( TO_CHAR( MM_DAYS.DAY, 'MM'),
'12', DECODE ( TO_CHAR( MM_DAYS.DAY+dd.N,'IW'), '01', '54', TO_CHAR(
MM_DAYS.DAY+dd.N,'IW')),
'01', DECODE ( TO_CHAR( MM_DAYS.DAY+dd.N,'IW'), '52', '00', '53', '00',
TO_CHAR( MM_DAYS.DAY+dd.N,'IW')),
TO_CHAR(MM_DAYS.DAY+dd.N, 'IW')
) AS week_num
FROM
( SELECT rownum-1 n from all_objects WHERE rownum <= 31 ) dd,
( SELECT to_date( '1.'||MM||'.'||YY, 'dd.mm.yy' ) DAY
FROM
( SELECT rownum MM from all_objects WHERE rownum <= 12 ),
( SELECT rownum YY from all_objects WHERE rownum <= 50 ) -- до 2050 - а почему нет? :)

) MM_DAYS
WHERE dd.N < TO_NUMBER(TO_CHAR(LAST_DAY( MM_DAYS.DAY ), 'DD'))
)
GROUP BY
DAY, week_num;
3 апр 03, 17:37    [164143]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
Crip
Member

Откуда:
Сообщений: 2490
Ну нет у MSSQL rowid...Ну что же поделать...
3 апр 03, 18:27    [164205]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
Chkalofff
Member

Откуда:
Сообщений: 4
Если какое-то программное средство накладывает определенные ограничения, то нужно смотреть не мешает ли это ограничение выполнению поставленной задачи.

Это полный бред, если считать, что ограничение на 17 вложенность является определяющей. В реальных условиях на планете Земля, если упирается в это, то это проблема в проектировании структуры БД.

Например, в c# есть jagged массивы. Но это не значит, что языки, которые их не поддерживают, становятся плохими по определению.

Вопрос стоит о реальной задаче. Назовите реальную задачу масштаба предприятия, с которой не справится MSSQL, но справится Oracle.

Что касается вставки n записей, что тут конечно может быть много причин, но возможно на других базах вы заранее аллокировали пространство для этого, а на MSSQL сделали базу размером 1mb по умолчанию. В процессе вставки системе пришлось постоянно ресайзить базу и лог. Хотя причин еще может быть туча. В любом случае, то что вы скрываете код этого теста от общественности, делая такими заявления, выгладить не очень убедительно.
3 апр 03, 18:45    [164227]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
DimaR
Member

Откуда:
Сообщений: 1570
Если средство не позволяет сделать то, что ты хочеш, меняй то что ты хочеш.
Если же средство не позволяет сделать то что НУЖНО то меняй средство.
(не помню кто сказал)

А в моем примере реч идет о вполне конкретной задаче для SQL пусть немного академической, иак сказать, но показывающей некоторые возможности.
Вот мне и хочеться увидеть, как это можно реализовать на других СУБД.
3 апр 03, 19:02    [164244]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
Glory
Member

Откуда:
Сообщений: 104751
Ну нашли блин чем меряться - календарями

set datefirst 1

select [week], [month],
ISNULL(max([ПН]), '') AS N'ПН',
ISNULL(max([ВТ]), '') AS N'ВТ',
ISNULL(max([СР]), '') AS N'СР',
ISNULL(max([ЧТ]), '') AS N'ЧТ',
ISNULL(max([ПТ]), '') AS N'ПТ',
ISNULL(max([СБ]), '') AS N'СБ',
ISNULL(max([ВС]), '') AS N'ВС'
from(
select datepart(wk, yy+mm+dd) AS [week], mm+'.'+yy AS [month],
case when datepart(dw, yy+mm+dd) =1 then dd ELSE NULL end AS N'ПН',
case when datepart(dw, yy+mm+dd) =2 then dd ELSE NULL end AS N'ВТ',
case when datepart(dw, yy+mm+dd) =3 then dd ELSE NULL end AS N'СР',
case when datepart(dw, yy+mm+dd) =4 then dd ELSE NULL end AS N'ЧТ',
case when datepart(dw, yy+mm+dd) =5 then dd ELSE NULL end AS N'ПТ',
case when datepart(dw, yy+mm+dd) =6 then dd ELSE NULL end AS N'СБ',
case when datepart(dw, yy+mm+dd) =7 then dd ELSE NULL end AS N'ВС'
from (select right('0'+cast(row_number as varchar(2)), 2) DD, row_number as dd1 from millenium where row_number <= 31) AS DD
cross join
(select right('0'+cast(row_number as varchar(2)), 2) MM from millenium where row_number <= 12) AS mm
cross join
(select '20'+right('0'+cast(row_number as varchar(2)), 2) YY from millenium where row_number <= 50) AS yy
where isdate(yy+mm+dd) = 1
) AS a
--where [month] = %af_src_str_26

group by [month], [week]
order by [month], [week]


- Внешний запрос(с ISNULL) сделан больше для удобства - можно обойтись и без него
- таблица millenium состоит из последовательности чисел от 1 до 1000
3 апр 03, 19:32    [164264]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
А мне вот интересно сможет ли Oracle решить вот это
Понятно что сможет, интересно за какое время
3 апр 03, 20:17    [164288]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
DimaR
Member

Откуда:
Сообщений: 1570
Дело в том, что в той задаче думает не сервер и не компьютер а тот кто набирает SQL запрос, а SQL испльзуеться как средство отображения хода мысли человека, с таким же успехом это может быть notepad,
И твой запрос просто переписываеться в синтаксис нужного SQL сервера.
3 апр 03, 20:30    [164292]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
AISOFT
Guest
DimaR
Дело в том, что в той задаче думает не сервер и не компьютер а тот кто набирает SQL запрос

Как интересно, в задаче с календарем, оказывается, думает сервер, а в примере, который привел SergSuper думает человек. В принципе, человек должен думать всегда, а не изредка.
3 апр 03, 21:11    [164311]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
DimaR
Member

Откуда:
Сообщений: 1570
AISOFT
1. Я извиняюсь, что ответил в этот топик по поводу той задачи, мне следовало там же и отвечать.
2. Мой пример (а точнее не мой, а взятый из другой конференции), просто показывает возможности SQL, а не претендует на какую либо аналитику.

А если начинать спорить о возможностях какая СУБД чего может, давайте откроем отдельный топик и на примерах SQL, процедур и прочего функционала будем обсуждать.
3 апр 03, 21:30    [164316]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
AISOFT
Guest
DimaR
Так я как раз и не хочу спорить о превосходстве того или иного сервера, более того я пытаюсь доказать, что по своим возможностям, для большинства задач, они примерно одинаковы. А то, что Oracle функционально богаче SQL SERVER, еще не определяет его превосходства. Как пример, достаточно вспомнить язык программирования PL\1, уж какой богатый был язык, ну и где он теперь?
3 апр 03, 22:02    [164328]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
mumu
Member

Откуда:
Сообщений: 9
Ребята! Я как-то спрашивал что выбрать из СУБД, если не ORACLE (потому что у начальства денех нет). Ответы были прямо скажем не лобовые. Результат: все-таки покупаем Oracle. Всем спасибо! Все могут выпить!..
3 апр 03, 23:03    [164341]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
AISOFT
Guest
mumu
Результат: все-таки покупаем Oracle.
А под какие задачи? И какой откат получит начальство?
3 апр 03, 23:07    [164342]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
ppp
Member

Откуда:
Сообщений: 278
to AISOFT
Vividi kakie to ne logichnie poluchajutsa, soglasivshis s tem chto что "Oracle функционально богаче SQL SERVER" delaesh vivod chto on ne luchshe,potomu chto "для большинства задач, они примерно одинаковы".
Eto kak k primeru sravnitj ziguli i mersedes - dlja bolshinstva perevozok passazirov primerno odinakovie mashini , obe spravlajutsa s postavlennimi zadachami, stalo bitj mersedes ne luchshe zigulej ?)))
Vivod vrode kak dolzen bitj chto Oracle luchshe s tehnicheskoj tochki zrenija , no dlja mnogih zadach on kak i mersedes ne nuzen.
3 апр 03, 23:14    [164345]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
ppp
Member

Откуда:
Сообщений: 278
to mumu
Nalivaj )))
3 апр 03, 23:16    [164347]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
>Результат: все-таки покупаем Oracle.
>А под какие задачи? И какой откат получит начальство?

докатились ... похоже последние аргументы уже исчерпаны
3 апр 03, 23:27    [164351]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
mumu
Member

Откуда:
Сообщений: 9
2 ppp
Я уже... и прилично. Чего и вам желаем...

>А под какие задачи? И какой откат получит начальство?
1. Неизвестно
2. Неизвестно
3 апр 03, 23:40    [164357]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
c127
Guest
2 Дед Маздай

>Не перевирайте цитату.
>
>The SQL Server 2000 advantages:
># SQL Server 2000 is cheaper to buy than Oracle 9i Database.
># SQL Server 2000 holds the top TPC-C performance and price/performance results.
># SQL Server 2000 is generally accepted as easier to install, use and manage.
>
>The Oracle 9i Database advantages:
># Oracle 9i Database supports all known platforms, not only the Windows-based platforms.
># PL/SQL is more powerful language than T-SQL.
># More fine-tuning to the configuration can be done via start-up parameters.
>
>Таким образом, в оригинале мощнее не Oracle как сервер баз данных, а его язык >программирования в серверной части.

И тут его мысль сделала гениальный скачок. (c)

Каким это "таким образом"? Откуда такой вывод?
Да из этой статьи можно только сделать вывод, что автор статьи, а вместе с ним возможно и Дед Маздай, не разбирается в предмете или сознательно передергивет. Читаем сначала. Цену и оборудование пока пропускаем, дальше идет "T-SQL vs PL/SQL". Поддержка B-tree индексов отнесена к свойствам T-sql. Таким образом поддержка ораклом 5 типов индексов (против одного у MSSQL по статье, но на самом деле двух, автор статьи наверное просто не знает) перекочевала из свойств сервера в свойства языка. И защитники MSSQL стыдливо признали, что да, T-SQL слегка уступает. Но проблема в том, что B-tree индексы, как впрочем и всякие другие есть не свойство языка, а свойство SQL-сервера. Так вот это не язык проигрывает по данному пункту, а сервер. Это же относится и к триггерам before incert и объектным таблицам: это не проблема языка, а проблема сервера. Имеем: из 5 пунктов по языку 3 отнесены к нему неправильно и следовательно не попали в сравнение собственно SQL серверов. По случайности это как раз те пункты, по которым MSSQL безусловно проигрывает (а индексы - вообще ключевой параметр).

Это по-моему самый большой прокол и его достаточно, чтобы понять, что статья несерьезная и дальше не читать.

Читаем дальше. Действительно, с длинными именами таблиц, сохраненок и пр. ораклу не повезло, придется ограничиться 30 символами. Что такое index length не могу понять, пробел в образовании, объясните кто может. А вот дальше опять начинаются интересные вещи.
max char() size: MSSQL - 8000, ORACLE - 2000;
max varchar() size MSSQL - 8000 ORACLE - 4000.
Это серьезно. А как же длинные документы хранить в оракле? А в CLOB-ах: You can apply character functions to CLOBs as if they were VARCHAR2 data. А в CLOB влазит по-моему до 4GB на винде. Автор статьи скромно умалчивает об этом. На всякий случай сообщаю: у оракла вообще нет (в oracle 8i точно не было) типа varchar, а есть varchar2.

Идем дальше.
constant string size in SELECT: MSSQL - 16777207, ORACLE - 4000;
constant string size in WHERE: MSSQL - 8000, ORACLE - 4000.

Явное преимущество MSSQL-я. Правда не понятно, что такое в данном контексте "constant string", может если сравнить "variable string size", то оракл выиграет, ну да ладно. Пусть знатоки оракла скажут за оракл, а я скажу за MSSQL: автор статьи нас за лохов держит. Хорошо известно, что MSSQL 7.x имел ограничение 256 таблиц в запросе. Это тяжелое наследие досталось ему от версии 6, которая имела ограничение 16 таблиц в запросе, включая копии. Даже написание седьмой версии практически с нуля (согласно деду Маздаю) не позволило мелкософтовским програмерам избавиться от этого ограничения, а только отодвинуть подальше. Звучит странно, но речь не о том. MSSQL2000 наверняка страдает наследственными болезнями. Поправьте меня, если я ошибаюсь. Пусть, этот лимит отодвинут, например, до 1024. Тогда на каждую из 1024 таблиц в запросе приходится 16777207/1024 байт, что составляет примерно 16383 байта на таблицу. Хотел бы я посмотреть на 16Кб запрос в котором всего одна таблица, даже килобайтный запрос с одной таблицей не представляю. Т.е. такая длина запроса просто смысла не имеет даже формально: мы раньше упремся в другое ограничение, о котором автор статьи тоже почему-то не вспоминает.

Но есть еще проблемка. По признанию автора статьи SQL диалект оракла мощнее такового в MSSQL-е. Следовательно запросы для оракла часто могут быть записаны либо более компакно либо вообще аналогов в T-SQL-е не имеют. Так чего стоит сравнение максимальной длины запроса в байтах, если на T-SQL-е его возможно вообще в чистом виде не запишешь, только через процедуры?

Все что осталось - цена и требования к оборудованию. Насчет оборудования - сильные у меня сомнения, но возможно автор прав. Хотя 8i требовал где-то вдвое меньше ресурсов, неужели девятка настолько тяжелее? А цена - да, MSSQL дешевле.

Эту статью вообще несерьезно приводить в качестве аргумента. Сомневающимся советую еще прочитать первую, та вообще больше на шутку похожа.
4 апр 03, 05:22    [164399]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
c127
Guest
2 AISOFT

>Зато выясняется, что MS посоветовал изменить структуру запроса, так это MS SQL SERVER плохой...

Говоришь неправду.

2 Chkalofff

>Это полный бред, если считать, что ограничение на 17 вложенность является определяющей. В реальных условиях на планете Земля, если упирается в это, то это проблема в проектировании структуры БД.

А я и не говорил, что это условие определяющее. Но приятного тоже мало. На самом деле цифра оказалась вполне реальной - 4. У мелеософта всегда так: по документации держит 256, но больше 10 заводить не рекомендуется, не заработает. Это низкий класс.

>Вопрос стоит о реальной задаче. Назовите реальную задачу масштаба предприятия, с которой не справится MSSQL, но справится Oracle.

Вопрос так не стоит (не стоял). Речь шла о задаче вообще. Я сформулировал задачу (точнее ограничил множество задач). Я не утверждал, что ее нельзя решить другими методами. Но на сях тоже можно все написать. Зачем эти SQL сервера повыдумывали?

Но если так хочется можно переформулировать: любая задача, решаемая ораклом и для решения которой необходимо построение запроса с 17 уровней вложенности представлений на MSSQ2000 не решается никак. Я не утверждаю, что задача существует. Это теоретический спор, к реальности отношения мало.

>Что касается вставки n записей, что тут конечно может быть много причин, но возможно на других базах вы заранее аллокировали пространство для этого, а на MSSQL сделали базу размером 1mb по умолчанию. В процессе вставки системе пришлось постоянно ресайзить базу и лог. Хотя причин еще может быть туча. В любом случае, то что вы скрываете код этого теста от общественности, делая такими заявления, выгладить не очень убедительно.

n записей мало, пусть будет m записей.
А что, по коду можно будет выяснить как база лог ресайзила? А потом появится законный вопрос об оборудовании и о настройках. Все настройки я и не знал никогда, как по умолчанию сервера встали, так и работали. Дело было на NT, ее нет под рукой, на вынь2K MSSQL7 наверное по-другому встанет.

Я не нашел скриптов, дело было 4 года назад. Скрипты простые, я могу попытаться повторить когда будет время, мне и самому интересно. Я повторял тест 2 раза в разное время с тем же результатом.

Еще раз о первоначальном предмете спора. Речь шла о том, что MSSQL прощает ошибки разработчиков и админов, а оракл нет. Я сказал, что это не так и в качестве контрпримера привел тот тест. С ораклом я разобрался, а с MSSQL-ем нет. В обоих случаях и читал документацию, менял настройки. Руки кривые? Но тогда получается что оракл проще, раз я кривыми руками его исправил, а MSSQL нет. А если руки прямые, то MSSQL кривой, раз прямыми руками его нельзя заставить нормально работать. Последний вариант - что я все выдумал.

Что же в моем примере некорректного, даже без скриптов? На малых базах оракл требует не больше внимания, чем MSSQL, а по моему опыту - меньше. Он страшнее, о его сложности ходят слухи, он дороже, его все бояться, но на самом деле всегда легче (для меня) в изучении и работе. Хотя и в нем кривизны выше крыши.
4 апр 03, 07:24    [164430]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
с127
Guest
Я понял, что такое "constant string size in SELECT" и "constant string size in WHERE". Признаю, тут MSSQL уделал оракла (с точностью до мощности PL/SQL, который возможно позволит избежать запросов, работающих со строками длиной 16777207. К тому же мы уже знаем, что вместо длинных строк в оракле можно использовать CLOB). Мое рассуждение относится к "max query size", но тут и без меня все хорошо.
4 апр 03, 07:47    [164436]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
AI
Member

Откуда: Москва
Сообщений: 2817
Есть еще одна вещь в оракле, но ее мало кто знает. Если поставить и сконфигурировать jserver (8.1 или 9.х), то максимальная длина имени объекта может превышать 30 символов, даже при неиспользовании java. То есть эта "слабость" оракла снимается...

2 с127
Действительно, 9 много тяжелее 8, но работает почему-то побыстрее.

2 AISOFT.
Компанию не назову - мне с ней работать еще. Но на оракуле проблемы, вызванные, как Вы сказали, ДНК разработчиков, не возникали...
4 апр 03, 12:55    [164859]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
AISOFT
Guest
AI
Но на оракуле проблемы, вызванные, как Вы сказали, ДНК разработчиков, не возникали...

А что, для Oracle и SQL Server, проектировала базу и писала код одна команда разработчиков?
4 апр 03, 13:39    [164935]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13633
Интересную тему я начал, не думал, что такая большая проблема сделать выбор между ЭМЭС ЭСКЬЮЕЛ и ОРАКЛ...

Похоже:


if( (сервер на Windows) && (будущие администраторы разрабатываемой системы с кривыми руками) )
MSSQL();
else
Oracle();


Как я понял, обе системы аналогичны, и спорить об этом бесполезно. Это все равно что также спорить об C++ Builder и Delphi. Такая же тема получится.

И всё-таки было бы интересно сравнить эти системы не на примере миллиона инсертов

(какой-то нереальный пример, если надо вставить миллион записей, тогда какой-нибудь БУЛК ИНСЕРТ надо использовать, но никак не SQL, это же какой сетевой траффик будет!!!, да и сервер зачем так насиловать?)

а на более жизненном примере. Меня например больше беспокоит, насколько оптимально работает оптимизатор "селекта" в MS SQL и насколько он отличается от аналогичного из ОРАКЛА.

Кстати, где можно почитать про оптимизатор запросов в MS SQL, желательно по-русски?
4 апр 03, 13:56    [164957]     Ответить | Цитировать Сообщить модератору
 Re: MS SQL Server FOREVER!?!?!  [new]
AISOFT
Guest
Алексей К
В принципе, надо выбирать сервер, который лучше знаешь. Хотя если сервер на Windows то SQL SERVER, в любом случае хороший выбор. В последнее время много и хорошо пишут о DB2, но я с ним не работал, поэтому ничего сказать не могу, но вполне возможно, что после более подробного изучения, я бы выбрал его, особенно если в дальнейшем будет необходимо обеспечить работу и на Unix и на Windows. Руки у разработчика должны быть прямые в любом случае и не надо думать, что SQL SERVER прощает серьезные ошибки, особенно в проектировании базы, хотя за счет своего оптимизатора, может простить некоторые, но не все, ошибки в кодировании.
4 апр 03, 14:38    [165039]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить