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

Откуда: СПб
Сообщений: 435
ЛП
2 Andreww
А как же типизация ?

По предыдущим обсуждениям вроде выяснили, что типизация - никак.
Всё есть строки.
Если строка выглядит как число, то она может обрабатываться как число. А может и нет. Храниться, впрочем, все равно в строковом виде будет.
Вроде так.

Со временем все меняется (не факт, что к лучшему). ИС в последних версиях Cache вводит неявную типизацию, т.е. и хранится нынче "123" и 123 по-разному. Что впрочем не мешает придерживаться старой концепции, в случае необходимости выполняются неявные преобразования.
24 окт 06, 16:34    [3303470]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MX -- ALEX
Guest
ЛП
2 Andreww
А как же типизация ?

По предыдущим обсуждениям вроде выяснили, что типизация - никак.
Всё есть строки.
Если строка выглядит как число, то она может обрабатываться как число. А может и нет. Храниться, впрочем, все равно в строковом виде будет.
Вроде так.


да - все так

например
set a="12.30 руб.цена "*"3 штуки"

установит в переменной "a" значение
36.9
которое далее может трактоваться или как число или как текст
- по смыслу программы
24 окт 06, 16:35    [3303483]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
И в базе что ли только строки хранятся ?
24 окт 06, 16:49    [3303633]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Andreww
И в базе что ли только строки хранятся ?

А как еще? описания же структуры нет, дерево может быть любым
24 окт 06, 16:55    [3303687]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MX -- ALEX
Guest
SergSuper
Andreww
И в базе что ли только строки хранятся ?

А как еще? описания же структуры нет, дерево может быть любым


на нижнем уровне - все так

на обьектном - другой разговор
24 окт 06, 17:12    [3303876]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
MX -- ALEX
например
set a="12.30 руб.цена "*"3 штуки"
установит в переменной "a" значение
36.9


Хм... Ох уж мне эти неявные преобразования...
Классика:
set a="12.30 руб.цена "*"3 штуки"
set b="12,30 руб.цена "*"3 штуки"
set c="123e-1 руб.цена "*"3 штуки"
set d="1'230'000.23 руб.цена "*"3 штуки"
24 окт 06, 18:11    [3304344]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
это не самое забавное
там еще вроде приоритетов в математических операциях нет
т.е. 2+2*10=40
или я чего путаю?
24 окт 06, 19:06    [3304663]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
andrey_anonymous
Member

Откуда: Москва
Сообщений: 19924
SergSuper
там еще вроде приоритетов в математических операциях нет
т.е. 2+2*10=40

Это не самое страшное, поскольку есть скобки.
А вот постоянные неявные преобразования - это родина сложноуловимых багов.
24 окт 06, 19:09    [3304676]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

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

Помимо багов, которые сложно, но можно (теоретически, если кол-во строк кода перевалило за 200.000 никто уже не возмётся искать) поймать, это ещё и потеря производительности, избавиться от которой невозможно - сервер вместо перед тем как просуммировать, сгруппировать,сортировать вынужден будет из строк в число переводить,и проверять корректная ли строка, кроме того нагрузка на диск возрастает, если строк много, затраты могут быть ощутимы :(
24 окт 06, 19:27    [3304728]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
pavelvp
Member

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

create table tree (
id int default autoincrement not null primary key,
level int not null check(level in(1,2,3)),
parent int not null references tree.id,
val text);


в M (msm - cache - gtm) такая команда создаст трехуровневое
дерево с одним элементом

set ^tree("игрушки","SQL детский","цена")=12.40

Неправда ваша. Конструкции неравнозначны. Ни семантически, ни функционально.
24 окт 06, 19:33    [3304738]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
SergSuper
Andreww
И в базе что ли только строки хранятся ?

А как еще? описания же структуры нет, дерево может быть любым


Реализации M-систем могут отличаться в этом плане. Так например, каше уже хранит типизированные данные в глобалах, если использовать стандартные стратегии хранения объектов в них, соответственно операции целыми числами и числами с плавающей запятой исполняются без доп. преобразований (версия 5.2)
24 окт 06, 20:00    [3304802]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
LittleCat
Member

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

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

Ну вот, Вы зачем-то пытаетесь домысливать... за сервер :-) Я не знаю, как все это устроено в Cache (открытого кода нет, а в бинарнике в этом месте я не ковырялся). Но например в GT.M локальные данные хранятся в структурах, в которых есть ОБА предстваления. Поля этих структур заполняются по мере надобности, и если поле заполнено, вторично преобразование уже не производится :-) Так что лучше не фантазировать, что и как сервер делает...
24 окт 06, 20:56    [3304914]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ЛП
Guest
LittleCat
Andreww
2 andrey_anonymous

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

Ну вот, Вы зачем-то пытаетесь домысливать... за сервер :-) Я не знаю, как все это устроено в Cache (открытого кода нет, а в бинарнике в этом месте я не ковырялся). Но например в GT.M локальные данные хранятся в структурах, в которых есть ОБА предстваления. Поля этих структур заполняются по мере надобности, и если поле заполнено, вторично преобразование уже не производится :-) Так что лучше не фантазировать, что и как сервер делает...

Однако это все-таки дополнительные проверки на заполненность "дублирующих" полей (каждый раз?), дополнительные преобразования (хотя бы раз), и уж совершенно точно еще более много места на диске.
24 окт 06, 21:00    [3304921]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
Rus000
c127
Понятность может быть, хотя тоже под вопросом, а вот краткость - нет. Было исследование в середине 80-х, по-моему ИБМ-а, там получилось что программист пишет примерно одинаковое количество операторов в час независимо от языка. Поэтому если задача не может быть решена меньшим числом оператором, т.е. если язык не компактный, то какие-то задачи за заданное время не решаются и требуют больше ресурсов (времени), а это проблема разработчика. Получается на практике компактность это разница между "задача решается" и "задача не решается".

в понятие компактность входит не только меньшее кол-во операторов, но и возможность их краткой записи.

Краткая запись на скорость разработки практически не влияет, нет существенной разницы пишите ли Вы "for" или "f", "begin" или "{", хотя мне лично больше нравится "{" . Всякие студии-визарды тоже не влияют. Во всяком случае в этом исследовании подчеркивалось, что использование интегрированных оболочек с встроенными подсказками не ускоряет программирования, по крайней мере они этой зависимости не нашли.

Rus000
c127
А по-моему СКЛ запросы читаются легче чем объектный код.

Думаю это Ваше "имхо". Не могли бы Вы выдернуть из одного из Ваших проектов самый объемный sql-запрос и показать его обществнности? А там уж посмотрим на его понятность

Конечно ИМХО, я и написал "по-моему".

Запрос:
select 1 from db.resource p, db.access v
where p.id=@resourceId and v.content=p.parent
and v.sessionId=@sessionId and access=2  --пользватель имеет право на редактирование содержимого ресурса

Rus000
c127

Опять двадцать пять, может не нужно ходить по кругу. Примеры компактности см. тут
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=54920&pg=12

опять началась эскалация ... Прочтите внимательно контекст в котором было высказано утверждение о компактности - "среди императивных, т.е. процедурных языков". А Вы про что?

Да, согласен, было лень подумать, никак не могу запомнить кто из них императивный а кто имплекативный. По-моему среди императивных М компактен не сам по себе, а за счет встроенных средств типа обхода деревьев и пары других. Без этого особой компактности бы не было, все императивные языки ИМХО примерно одинаковые в смысле количества операторов на задачу.

Rus000

Я показал компактность записи кода на минимально четко очерченной и понятной все задаче обхода дерева. Вы сделали акцент на использовании "родной" структуры - что ж здесь тоже есть свои плюсы почему бы ими не пользоваться.

Я не против, пользуйтесь на здоровье. Мое утверждение состояло в том, что эти плюсы на реальных задачах могут быть использованы гораздо реже, чем Вы думаете.

Rus000

c127

Но оказывается что в жизни таких структур мало, именно по этой причине

ну вот приехали! Что значит мало!? В реальных задачах вообще структур нет, и их придумывают проектировщики и программеры на основании упрощенной модели реально процесса, именно они выбирают оптимальную стратегию хранения данных в ИС.

Более строго это значит что малое число задач может быть естественным образом выражено в терминах таких структур. Дерево слишком частный вид графа.

Rus000

А разве Вы не знаете, что одноуровневое дерево (ключ-значение) эквивалентно реляционному отношению? И что концептуальная структура данных выраженная в РМД выразима и терминах одноуровненвых деревьев?

Я это знаю, более того, мы это обсуждали с Вами по-моему. Обратите внимане: "одноуровненвых деревьев". Деревьев Вам в общем случае требуется много. А естественным образом Вы работать умеете только с одним деревом, связывать деревья в иерархических базах сложно, все преимущества иерархических БД при этом пропадают.

Rus000

не могли бы Вы привести пример скажем минимального трехуровневого дерева в Вашей структуре? мне интересно как это будет выглядеть

В том топике, на который я ссылалася по-моему есть пример. Вот еще
insert into tree (id,parent,val) values (0,0,'root');
insert into tree (id,parent,val) values (1,0,'level1 vert_0');
insert into tree (id,parent,val) values (2,1,'level2 vert_0');
insert into tree (id,parent,val) values (3,0,'level1 vert_1');
25 окт 06, 00:13    [3305241]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
c127
Guest
Виноват, не имплекативный, а импликативный.
25 окт 06, 00:24    [3305256]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MX -- ALEX
Guest
ЛП
LittleCat
Andreww
2 andrey_anonymous

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

Ну вот, Вы зачем-то пытаетесь домысливать... за сервер :-) Я не знаю, как все это устроено в Cache (открытого кода нет, а в бинарнике в этом месте я не ковырялся). Но например в GT.M локальные данные хранятся в структурах, в которых есть ОБА предстваления. Поля этих структур заполняются по мере надобности, и если поле заполнено, вторично преобразование уже не производится :-) Так что лучше не фантазировать, что и как сервер делает...

Однако это все-таки дополнительные проверки на заполненность "дублирующих" полей (каждый раз?), дополнительные преобразования (хотя бы раз), и уж совершенно точно еще более много места на диске.


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

проблемы есть - но другие - скорее для программистов, а не компа:
-- документация тяжелая (CACHE) и нерусская
-- лицензии не бесплатные
-- инструменты для разработчика дорогие
-- код непривычный для большинства

однако готовый продукт - для потребителя - можно сделать
очень крутым - и - достаточно быстро - если знать как

часто это главное
25 окт 06, 00:40    [3305277]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ЛП
Guest
2 MX -- ALEX
диск ни при чем
локальные - это в оперативной памяти

О, простите...
Было сказано, что "локальные данные хранятся в структурах", а для меня (по-привычке) слово "хранятся" - это все-таки на диске.

Если у Вас например стогиговая база - сколько таких "двойных" структур Вы будете "хранить" в памяти сервера?
25 окт 06, 00:50    [3305287]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
MX -- ALEX
Guest
ЛП
2 MX -- ALEX
диск ни при чем
локальные - это в оперативной памяти

О, простите...
Было сказано, что "локальные данные хранятся в структурах", а для меня (по-привычке) слово "хранятся" - это все-таки на диске.

Если у Вас например стогиговая база - сколько таких "двойных" структур Вы будете "хранить" в памяти сервера?


простая операция
set a=b+c

для ее выполнения надо
1-- найти "в справочнике" и интерпретировать в машинный код саму команду "set"
2-- найти b,с в области размещения переменных в оперативной памяти
3-- сложить - с преобразованием типов "строка/число"
3-- найти где сидит "a" (если она уже есть) и посадить туда "a" новое

все "найти" (1,2,4) - особенно если локальных
переменных уже много - сжирают несравнимо больше времени
чем преобразование типов

вот это действительно узкое место в системах с интерпретатором
к которым относится MSM - CACHE - GTM
25 окт 06, 08:51    [3305577]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Rus000
Member

Откуда: Красноярск
Сообщений: 317
c127, спасибо за коменты, по большому счету мне и возражать особо не на что :)

c127

Я это знаю, более того, мы это обсуждали с Вами по-моему. Обратите внимане: "одноуровненвых деревьев". Деревьев Вам в общем случае требуется много. А естественным образом Вы работать умеете только с одним деревом, связывать деревья в иерархических базах сложно, все преимущества иерархических БД при этом пропадают.


это если делать перенос рел.структуры в лоб, а на деле часто оказывается, что сущности более понятно представимы в виде достаточно ветвистого многоуровнего дерева. В частности, например такая сущность как "человек" может быть совершенно прозрачно декомпозирован в дереве на "работник", "пенсионер", "льготник", "получатель медуслуг", "вкладчик" и т.п., каждый из таких категорий может быть уточнена еще более подробным способом путем ветвления нижних уровней. В итоге получается, вообще говоря, логически несбалансированное разреженное дерево, которое определяет ВСЮ совокупность реквизитов и подсущностей для человека. Деревянный подход очень похож на объектный.

Я допускаю, что проектировать можно и в другом наборе сущностей и связей, но вопрос какая модель все-таки более интуитивно понятна.
25 окт 06, 09:08    [3305642]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
Andreww
Member [заблокирован]

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

"GT.M локальные данные хранятся в структурах"

Локальные это в памяти или на диске ?

Если в памяти то, да, нагрузка на диск возрастает : ту память вы могли использовать как буфер для страниц - используется для числового представления строк (как заметил "ЛП" для базы большого размера это ощутимая величина), размеры буферов уменьшаются - на диск надо лазить чаще, а переводить строку и проверять её на правильность после чтения всё равно придётся. Это не "домысливание", это "физика" работы системы, причём не самая мудрёная, если у КАШЕ,М,GT.M придумано нечто принципиально новое - рассказывайте что, всем будет ОЧЕНЬ интересно.

2 MX-ALEX

Читать про то как работают интерпретаторы, до просветления.
Интерпретация ТЕКСТА осталась в прошлом уже лет 20 как, по тем причинам что вы написали + некоторые другие.

Современные интерпретаторы умеют генерировать промежуточный p-код, байт-код (не путать с кодом виртуальной машины), в котором, как раз, вместо строковых команд и мнемонических имён стоят идентификаторы, условные выражения и строковые переменные разобраны, арифметические выражения разобраны и прочее.

Если какая-то система зависла в прошлом и до сих пор интерпретирует текст не значит, что все поступают также.

2 RUS000

"на деле часто оказывается, что сущности более понятно представимы в виде достаточно ветвистого многоуровнего дерева"

Обсуждалось уже раз 20, представимы-то они представимы, но надо чётко представлять какие будут запросы иначе эффективность работы с деревом теряется :

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=31638&pg=12#1118154

https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=31638&pg=16#1122252
25 окт 06, 10:13    [3306069]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Rus000
SergSuper
Andreww
И в базе что ли только строки хранятся ?

А как еще? описания же структуры нет, дерево может быть любым


Реализации M-систем могут отличаться в этом плане. Так например, каше уже хранит типизированные данные в глобалах, если использовать стандартные стратегии хранения объектов в них, соответственно операции целыми числами и числами с плавающей запятой исполняются без доп. преобразований (версия 5.2)
А можно пример описания дерева? Так сказать DDL от каше
25 окт 06, 10:24    [3306136]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
LittleCat
Member

Откуда: СПб
Сообщений: 435
ЛП
2 MX -- ALEX
диск ни при чем
локальные - это в оперативной памяти

О, простите...
Было сказано, что "локальные данные хранятся в структурах", а для меня (по-привычке) слово "хранятся" - это все-таки на диске.

Если у Вас например стогиговая база - сколько таких "двойных" структур Вы будете "хранить" в памяти сервера?

Ну извиняйте, для любого мампсиста локальная (по-привычке), это всегда в оперативной памяти. Поэтому сколько будет локальных переменных, столько и будет этих структур. Памяти пока хватает :-) Опять же рассуждать о том, что это плохо, нужно в сравнении с чем-то, иначе это пустые домыслы. Вот если привести в противовес, как там это дело в других БД организовано, тогда понятно. А так дилетантизм получается :-)
25 окт 06, 11:27    [3306701]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ЛП
Guest
LittleCat
ЛП
2 MX -- ALEX
диск ни при чем
локальные - это в оперативной памяти

О, простите...
Было сказано, что "локальные данные хранятся в структурах", а для меня (по-привычке) слово "хранятся" - это все-таки на диске.

Если у Вас например стогиговая база - сколько таких "двойных" структур Вы будете "хранить" в памяти сервера?

Ну извиняйте, для любого мампсиста локальная (по-привычке), это всегда в оперативной памяти. Поэтому сколько будет локальных переменных, столько и будет этих структур. Памяти пока хватает :-) Опять же рассуждать о том, что это плохо, нужно в сравнении с чем-то, иначе это пустые домыслы. Вот если привести в противовес, как там это дело в других БД организовано, тогда понятно. А так дилетантизм получается :-)

Если Вы не поняли, то поясню. Я ничего не имею против оперативной памяти, против оперативной памяти на сервере, и даже против оперативной памяти на клиенте. Я против хранения там информации (если речь не идёт об in-memory databases, к коим Каше себя не причисляет). Зачем было говорить, что сервер "что-то" (например преобразованные из строк числа) там хранит, в то время как это "что-то" просто болтается в оперативной памяти как говно в проруби, ровно до тех пор, пока его оттуда со свистом не вынесет необходимость обработать следующий запрос от следующего клиента?

Вернемся к нашим алфавитно-цифровым баранам. Перепопытка номер два.

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

В ответ на это пытались отмазаться что дескать "у неё унутре думатель и неонка, думатель один раз посчитает, неонка все сохранит". Отмазаться не получилось, потому что не получилось сохранить.

Теперь начались песни что дескать "не тормозит преобразование хоть сколько нибудь ощутимо - это ничтожная доля от общего времени работы программ" (с) MX--ALEX
Оно конечно смешно, но суммирование тоже не тормозит сколько нибудь ощутимо - до тех пор, пока суммировать не приходится миллионы чисел. Видимо и преобразование не тормозит ровно до тех же самых пор. А про то, что все летает на 220% - мы уже слышали.
25 окт 06, 13:50    [3308237]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
LittleCat
Member

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

Если Вы не поняли, то поясню.

Да Ваши пояснения мы поняли - в М-системах все плохо. Еще раз повторюсь, расскажите, где хорошо, какие механизмы лучше, где не существует никаких проверок и накладных расходов.
25 окт 06, 14:34    [3308736]     Ответить | Цитировать Сообщить модератору
 Re: CACHE и MSSQL  [new]
ЛП
Guest
LittleCat
ЛП

Если Вы не поняли, то поясню.

Да Ваши пояснения мы поняли - в М-системах все плохо. Еще раз повторюсь, расскажите, где хорошо, какие механизмы лучше, где не существует никаких проверок и накладных расходов.

Вам что, действительно необходимо рассказать про то, что если система хранит числа как числа, а не как строки с написанием числа, не как картинки с изображением числа, и не как звуковые файлы с произношением числа - то этой системе не приходится заниматься конвертацией, проверками, да и по объему оно поменьше будет?

Или Вам пальцем показать на СУБД, хранящие числа как числа? У меня, простите, пальцев не хватит :)
25 окт 06, 15:06    [3309102]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10 .. 106   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить