Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 .. 106   вперед  Ctrl
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
andrey_anonymous
Sergei Obrastsov
P.S. 2andrey_anonymous
Ну и зачем понадобился "ЛП"? Чтобы создать впечатление толпы? Или чтоб не
портить о себе впечатление?

Меня иногда подозревают в клонировании, но в данном случае у меня твердое алиби - с моих ip гестов не пускают.

andrey_anonymous
ЛП
извините
- потярялся не полкило, а поллитра :)

С поллитры и не так потеряться можно.

Сорри, не удержался

Я сделал вывод.
26 окт 06, 12:42    [3313786]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MX -- ALEX
Guest
andrey_anonymous
LittleCat
andrey_anonymous

Вы неправы. Показывать или просто поверите? =)

Про что неправ ? Если про что-то в SQL, так поверю

Именно.
Не знаю как в MSSQL, а в оракеле можно и пользовательские функции в запросах, и пользовательский оператор создать, и агрегатную функцию, и очень удобную в ряде применений pipelined, включаемую непосредственно в конвейер sql-машины.


Андрей - авторитетный мужик
верю
26 окт 06, 12:42    [3313792]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
andrey_anonymous
LittleCat
andrey_anonymous

Вы неправы. Показывать или просто поверите? =)

Про что неправ ? Если про что-то в SQL, так поверю

Именно.
Не знаю как в MSSQL, а в оракеле можно и пользовательские функции в запросах, и пользовательский оператор создать, и агрегатную функцию, и очень удобную в ряде применений pipelined, включаемую непосредственно в конвейер sql-машины.

Тут погорячился, признаю.
26 окт 06, 12:44    [3313815]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
Sergei Obrastsov
Я сделал вывод.

Если честно, я промахнулся со смайлом - меня порадовал каламбур от ЛП и хотелось этот факт отметить.
А "сорри не удержался" в оригинальной идее относилось к самому посту как к оффтопичному.
Но промазал и вместо скалозуба получилось нечто крайне неоднозначное - я сам сумел найти две различных трактовки, Вы дали третью :)
Прошу прощения если ввел в заблуждение.
26 окт 06, 12:46    [3313838]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
andrey_anonymous

Я не добавляю сущностей, но просто уточняю, что помимо собственно логики решения этот запрос реализует еще и логику многопользовательского доступа к данным довольно прозрачным с точки зрения разработки/поддержки образом без дополнительного кодирования, как любят отмечать адепты MUMPS :).

Еще раз хочу напомнить, фраза без дополнительного кодирования относилась только к вопросу преобразования число-строка и строка-число при операциях с данными, не надо обобщать :-)
26 окт 06, 12:47    [3313845]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
LittleCat
andrey_anonymous

Я не добавляю сущностей, но просто уточняю, что помимо собственно логики решения этот запрос реализует еще и логику многопользовательского доступа к данным довольно прозрачным с точки зрения разработки/поддержки образом без дополнительного кодирования, как любят отмечать адепты MUMPS :).

Еще раз хочу напомнить, фраза без дополнительного кодирования относилась только к вопросу преобразования число-строка и строка-число при операциях с данными, не надо обобщать :-)

Это был туз в рукаве на всякий пожарный, но при умных и адекватных оппонентах он так и не пригодился :)
26 окт 06, 12:49    [3313864]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Sergei Obrastsov
Member

Откуда: Магадан
Сообщений: 584
andrey_anonymous
Sergei Obrastsov
Я сделал вывод.

Если честно, я промахнулся со смайлом - меня порадовал каламбур от ЛП и хотелось этот факт отметить.
А "сорри не удержался" в оригинальной идее относилось к самому посту как к оффтопичному.
Но промазал и вместо скалозуба получилось нечто крайне неоднозначное - я сам сумел найти две различных трактовки, Вы дали третью :)
Прошу прощения если ввел в заблуждение.

Ну вот, обознался я, значит. Прошу простить. Хотя выглядит действительно как ошибка, только в выборе ника. :)

2ЛП - Тоже прошу прощения. Но только за это.
26 окт 06, 12:53    [3313919]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 andrey_anonymous

К вопросу о преобразованиях :

"Именно поэтому среды с четкой типизацией предпочтительней (а вовсе не из соображений performance, как нередко полагают необстрелянные программисты :)"

Среды разработки приложений - да, базы данных - нет.

База которая всё хранит в строках должна либо уйти в историю, либо измениться.
26 окт 06, 13:26    [3314267]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
Andreww
"Именно поэтому среды с четкой типизацией предпочтительней (а вовсе не из соображений performance, как нередко полагают необстрелянные программисты :)"

Среды разработки приложений - да, базы данных - нет.

База которая всё хранит в строках должна либо уйти в историю, либо измениться.

Читал со всех сторон но так и не понял, что же Вы хотели сказать.
26 окт 06, 13:46    [3314469]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MX -- ALEX
Guest
andrey_anonymous
Andreww
"Именно поэтому среды с четкой типизацией предпочтительней (а вовсе не из соображений performance, как нередко полагают необстрелянные программисты :)"

Среды разработки приложений - да, базы данных - нет.

База которая всё хранит в строках должна либо уйти в историю, либо измениться.

Читал со всех сторон но так и не понял, что же Вы хотели сказать.


что делать с тысячами тонн печатных документов
хранящихся в архивах ?
там ведь только текстовые строки ..
26 окт 06, 14:57    [3315153]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 andrey_anonymous

Хм.....

Берём оракел 9.2 таблица из одного поля (number) на 2е6 записей, сложить всё (select sum(f1) from t1) ~ 1.38 сек.

Другая таблица из одного поля (но уже varchar2) на 2е6 записей, сложить всё (select sum(to_number(f1)) from е2) ~ 2.37 сек.

В эту разницу попадает операция перевода строки в число и лишнее считывание блоков, вывод прост - СО СТРОКАМИ МЕДЛЕННЕЕ и РАЗНИЦА ОЩУТИМА.

Можно возразить что в "чудодейственных М системах" функции перевода строки в число круты, а в ненужных "Р"СУБД (с) всё криво.


Хорошо, берём вожделенную GT.M (будующее человечества, блин), выдираем из неё функцию конвертации (замучался искать, но результат в аттаче),
прогоняем её в цикле 2е6 раз (конвертируем строку "5.12XXX", конвертится в число 5.12 без проблем), на 2е6 вызовов всего тратится ~ 0.7 мсек.

Т.е., за свои же деньги, нагружать будете процессор НЕНУЖНЫМИ ОПЕРАЦИЯМИ.

Вот и весь "смысл".

К сообщению приложен файл (s2n.c - 3Kb) cкачать
26 окт 06, 15:10    [3315262]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 MX-ALEX

>>что делать с тысячами тонн печатных документов
>>хранящихся в архивах ?
>>там ведь только текстовые строки ..

Читаем ещё раз, внимательнее :

База которая ВСЁ хранит в строках должна либо уйти в историю, либо измениться.

Подсказка : ключевое слово ВСЁ.

Кстати, кроме строк в ТОННАХ АРХИВНОЙ БУМАГИ ещё как минимум даты есть, по которым искать бывает нужно.
26 окт 06, 15:14    [3315298]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
Andreww
2 andrey_anonymous
Берём оракел 9.2

Так вот Вы о чем... Сразу не догнал, цитатка и формулировка уж больно неоднозначно друг другу соответствуют :)

Разница может быть ощутима сколько угодно раз, но до тех пор, пока она не стала критичной для конкретной бизнес-операции - это не имеет ровным счетом никакого значения.
Что до оракеля 9.2... Для Вас же не секрет, что oracle number - это BCD с плавающей точкой и точно также нуждается в преобразовании перед вычислениями?
Подозреваю, что IEEE REAL(8) или IEEE REAL(10) могли бы быть еще шустрее... Вот только надо оно кому?
Результат Вашего теста будет гораздо сильнее зависеть от таких банальностей как PCTFREE и средняя длина строки (добавьте колоночку payload char(500) not null default ' ') и повторите эксперимент.
А если еще вспомнить про соединения и сортировки, то процент "лишней" работы может и совсем затеряться...
26 окт 06, 15:34    [3315459]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
Да, и еще - мое утверждение про предпочтения касалось только "классических" применений БД.
Есть применения, где ситуация обратная - это, к примеру, системы content management и поисковые системы типа того же google - т.е. применения, в значитальной степени завязанные на контекстный поиск.

2Andreww:
Кстати, о птичках: обратный результат теста на "oracle 9.2" сами получить сумеете? =)
26 окт 06, 15:46    [3315555]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MX -- ALEX
Guest
Andreww
2 andrey_anonymous

Хм.....

Берём оракел 9.2 таблица из одного поля (number) на 2е6 записей, сложить всё (select sum(f1) from t1) ~ 1.38 сек.

Другая таблица из одного поля (но уже varchar2) на 2е6 записей, сложить всё (select sum(to_number(f1)) from е2) ~ 2.37 сек.

В эту разницу попадает операция перевода строки в число и лишнее считывание блоков, вывод прост - СО СТРОКАМИ МЕДЛЕННЕЕ и РАЗНИЦА ОЩУТИМА.

Можно возразить что в "чудодейственных М системах" функции перевода строки в число круты, а в ненужных "Р"СУБД (с) всё криво.


Хорошо, берём вожделенную GT.M (будующее человечества, блин), выдираем из неё функцию конвертации (замучался искать, но результат в аттаче),
прогоняем её в цикле 2е6 раз (конвертируем строку "5.12XXX", конвертится в число 5.12 без проблем), на 2е6 вызовов всего тратится ~ 0.7 мсек.

Т.е., за свои же деньги, нагружать будете процессор НЕНУЖНЫМИ ОПЕРАЦИЯМИ.

Вот и весь "смысл".


ну секономим 0.0007 сек - разбогатеем ?

например в производственных делах помимо чисел
столько всякой текстовой фигни в архивах - и в числа не превратить !
те же номера документов
1232344
4454555
казалось бы числа
ан нет - появляется
1232344/A
и что - переделывать программу ?

и вообще не царское это дело - биты считать
пусть железо думает как хранить данные плотно и без дырок
26 окт 06, 15:51    [3315593]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MX -- ALEX
Guest
Andreww
2 MX-ALEX

>>что делать с тысячами тонн печатных документов
>>хранящихся в архивах ?
>>там ведь только текстовые строки ..

Читаем ещё раз, внимательнее :

База которая ВСЁ хранит в строках должна либо уйти в историю, либо измениться.

Подсказка : ключевое слово ВСЁ.

Кстати, кроме строк в ТОННАХ АРХИВНОЙ БУМАГИ ещё как минимум даты есть, по которым искать бывает нужно.


..которые то уж точно на бумаге в виде FLOAT прописаны
26 окт 06, 15:57    [3315648]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 andrey_anonymous

Так вот Вы о чем... Сразу не догнал, цитатка и формулировка уж больно неоднозначно друг другу соответствуют :)

:( Ну вам виднее .....

"Результат Вашего теста будет гораздо сильнее зависеть от таких банальностей как PCTFREE и средняя длина строки (добавьте колоночку payload char(500) not null default ' ') и повторите эксперимент."

Ага, а если одна таблица на дискете, а вторая на RAM диске то вааааще...

"А если еще вспомнить про соединения и сортировки, то процент "лишней" работы может и совсем затеряться..."

"Кстати, о птичках: обратный результат теста на "oracle 9.2" сами получить сумеете? =)"

Я что мог, провёл, то, что дисковая система узкое место, в отличии от процессора я догадываюсь и догадываюсь что есть операции которые выполняются много дольше чем преобразования :), при прочих равных (насколько у меня получилось) - преобразование есть нагрузка на систему (и нагрузка никому не нужная). Есть чего показать - показывайте :)
26 окт 06, 16:35    [3316034]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
Andreww
"Кстати, о птичках: обратный результат теста на "oracle 9.2" сами получить сумеете? =)"
при прочих равных (насколько у меня получилось) - преобразование есть нагрузка на систему (и нагрузка никому не нужная). Есть чего показать - показывайте :)

welcome to mystery:

SQL> desc ane_t;
Name Type          Nullable Default Comments 
---- ------------- -------- ------- -------- 
N    NUMBER        Y                         
V    VARCHAR2(100) Y                         

SQL> select count(*) from ane_t;

  COUNT(*)
----------
   1000000

SQL> set timing on
SQL> select sum(v) from ane_t;

    SUM(V)
----------
1250005000

Executed in 0.03 seconds

SQL> select sum(n) from ane_t;

    SUM(N)
----------
1250005000

Executed in 0.321 seconds

SQL> 
26 окт 06, 17:11    [3316372]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
andrey_anonymous
welcome to mystery:

Ладно, пока в подлоге не обвинили - отгадка:
SQL> alter session set query_rewrite_enabled=false;

Session altered

Executed in 0.02 seconds

SQL> select sum(v) from ane_t;

    SUM(V)
----------
1250005000

Executed in 0.781 seconds

SQL>
26 окт 06, 17:25    [3316507]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 andrey_anonymous

Решили поучить меня ораклу или ....?

Я вобщем не настолько искушен в трюках с параметрами, но если вы просто создали Mat.View это даже не смешно, это слив засчитан :)

Если нет - изложите, пожалуйста, в чём суть :)
26 окт 06, 17:50    [3316713]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
Andreww
2 andrey_anonymous
Решили поучить меня ораклу или ....?
А разве мы в привате переписываемся?
Мне казалось, что это публичный форум и читаем его не только мы с Вами...
В привате я так быстро бы не сдался ;)
Andreww
Я вобщем не настолько искушен в трюках с параметрами, но если вы просто создали Mat.View это даже не смешно, это слив засчитан :)

Какой такой павлин-мавлин?
Обратный Вашему результат есть?
Есть.
В данном конкретном случае было именно mat. view.
Средства достижения - отдельный вопрос, на данной задаче я знаю еще как минимум два способа (правда, для маскировки придется делать запросы к разным таблицам :)
26 окт 06, 17:57    [3316766]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 andrey_anonymous

Всё таки защитан ....

Обидно, на секунду показалась, кака революция свершилась а я проспал:(

"Куль хацкеры", которые чего-то там маскируют мне не очень интересны, хотя они очень нужны и полезны.

Но всё равно забавно :)
26 окт 06, 18:02    [3316814]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
Andreww
Всё таки защитан ....

Не согласен.
Все способы сравнительно честные и встречаются в реальной жизни, так что никакого слива не было.
Более того, в контексте топика я жду ответного хода от MUMPSистов - должны же они как-то парировать :)
26 окт 06, 18:07    [3316862]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
andrey_anonymous

Более того, в контексте топика я жду ответного хода от MUMPSистов - должны же они как-то парировать :)

Навеяло: Приходят физики-экспериментаторы к физикам-теоретикам и жалуются. Вот, мол, экспериментальные данные получили, вот график, но как-то он хреново с теорией согласуется. Теоретики покумекали и разложили все по полочкам. Экспериментаторы удовлетворенные уже уходит собрались, и тут один восклинул "Блин, да мы же вам график вверх ногами показали". "Ну тогда объяснить еще проще" - сказали теоретики.
26 окт 06, 18:16    [3316929]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
Sergei Obrastsov

Я верю. Мне просто интересно, где Вы нашли добавление ребра между вершинами?
Это кто-то предложил или Вам просто так кажется?
По-моему, это просто физически невозможно сделать в M.

Я говорил о логической схеме, ребро существует логически. В М его создать скорее всего действительно невозможно, поэтому вместо создания простого ребра его приходится сложно моделировать средствами М. Например можно создать другое дерево, где это ребро есть, но прийдется поддерживать целостность между двумя деревьями, см. пример с билетами. Это и есть проблемы. Иерархические БД появились раньше реляционных, но почти все вымерли именно по той причине, что логическая схема почти всякой задачи имеет циклы. Возможно есть и другие проблемы, но эта самая очевидная. Термин "логическая схема" тут используется условно.
27 окт 06, 00:03    [3317847]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить