GlebZ wrote:

> S>Нет, зачем? Для справки: исчисление функций, где есть функция 0,
> инкремент, и выбор n-ого аргумента, является turing-complete.
> Все — начинаю все писать в SQL.
> Смешно. Зачем цепляться за термины. Вполне понятно что для многих вещей
> он не применим без T-SQL. Он легко справляется с четко поставленной
> задачей, но не более того.
Он наврал, SQL не является Turing-complete (чистый, конечно). А вот T-SQL-надстройка — да, там всякие циклы и прочее.
Вот поэтому я и не люблю его использовать и другим не рекомендую — нарушает концептуальную чистоту... Лишь ради одного
может быть оправдано — гонка за производительностью.

Sinclair wrote:
> C>Единственное, при физическом перемещении объекта (в результате изменения
> C>размера, например) придется обновлять ссылающиеся на него объекты. А
> C>будет ли это частой операцией?
> Конечно же будет. А ты как хотел? Иначе наш файл окажется крайне
> дырявым.
Не обязательно. Дырявым он будет если объекты удаляются, но не
пересоздаются (в противном случае дырки можно переиспользовать для новых
объектов).

> СУБД без физического перемещения в природе не бывает. Причем,
> что характерно, перемещается как правило не один объект, а сразу пачка.
Пачки как раз хорошо оптимизируются.

Здравствуйте, stalcer, Вы писали:

S>Моя твоя непониает,
S>Рассудок мой изнемогает.
S>И т.п.

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

Здравствуйте, Sinclair, Вы писали:

GZ>>Такие простые выражения — да. Но если посложней, то уже идет переход на курсоры.
S>Ну например?

Ну например расчет налога на доход. Там в императивном виде несколько экранов кода с кучей IF. Что это будет ввиде SQL я боюсь даже представить.

Здравствуйте, Cyberax, Вы писали:
C>Не обязательно. Дырявым он будет если объекты удаляются, но не
C>пересоздаются (в противном случае дырки можно переиспользовать для новых
C>объектов).
Не получится. См. "фрагментация памяти".

Здравствуйте, kan_izh, Вы писали:
_>Неверно. Оператор рекурсии забыл.
Ай! Позор на мою плешивую голову.

Здравствуйте, AndrewVK, Вы писали:

Блин! Я думал, все, закончилась ветка .

AVK>Иван прав, на типовых системах, как настольных, так и серверных, самую тяжелую нагрузку создают выборки по рабочим таблицам, которые состоят из сотен тысяч или миллионов записей, да еще с джойнами на десяток-другой справочников. По сравнению с этим выборки единичных записей по первичному ключу для современной техники сущие мелочи.

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

Sinclair wrote:
> C>Не обязательно. Дырявым он будет если объекты удаляются, но не
> C>пересоздаются (в противном случае дырки можно переиспользовать для новых
> C>объектов).
> Не получится. См. "фрагментация памяти".
Почему не получится? Объекты обычно имеют один размер, так что все
вполне нормально.

Ну и периодический запуск пылесоса тоже вполне возможен.

Здравствуйте, Cyberax, Вы писали:
C>Почему не получится? Объекты обычно имеют один размер, так что все
C>вполне нормально.
Это где ж такие объекты выдают? Стоит добавить одно строковое поле — и упс, приплыли.
C>Ну и периодический запуск пылесоса тоже вполне возможен.
стоимость пылесосения, имхо, может оказаться неприемлемой.

Sinclair wrote:
> C>Почему не получится? Объекты обычно имеют один размер, так что все
> C>вполне нормально.
> Это где ж такие объекты выдают? Стоит добавить одно строковое поле — и
> упс, приплыли.
Смотря какие строки — если ограниченые, то все нормально. Я же не
утверждаю, что оно для всех случаев идеально

> C>Ну и периодический запуск пылесоса тоже вполне возможен.
> стоимость пылесосения, имхо, может оказаться неприемлемой.
Может. Все от задачи зависит.

Cronos

Здравствуйте, stalcer, Вы писали:

S>Блин! Я думал, все, закончилась ветка .

Если она тебе так мешает — не читай.

S>Во-первых, "джойны на десяток-другой справочников" — это и есть доступ по первичному ключу.

Не совсем. Джойн выполняет движок БД, и выполняет ее сразу над набором, поэтому обычно эта операция несколько больше, нежели простая навигация. Например, как уже Антон говорил, здесь может учитываться статистика, возможности чего, при явном задании навигации, движок лишен.

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

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

Здравствуйте, Cyberax, Вы писали:

C>GlebZ wrote:
>> S>Зато апдейт будет O(N). Такая модель неприемлема для нестатических БД.
>> Вообще-то поиск для aпдейт легко можно уменьшить (с помощью bitmap
>> индекса). Другой вопрос что O(1) сделать трудновато. Хотя бы потому что
>> нужно адресоваться по индексу, и адресация для страниц — подразумевает
>> O(log N).
C>Почему, просто записываем в OID физическую позицию в файле.
Не получится, индекс(а в особенности hash) как и страницы имеют тенденцию менять свой размер. А следовательно — перемещаться. Так что адрес по любому должен быть втой, или иной мере косвенным.
Если говорить об oid, то в ООБД есть понятия логического и физического OID.

GlebZ wrote:
> C>Почему, просто записываем в OID физическую позицию в файле.
> Не получится, индекс(а в особенности hash) как и страницы имеют
> тенденцию менять свой размер. А следовательно — перемещаться. Так что
> адрес по любому должен быть втой, или иной мере косвенным.
Индексы и блобы, естественно, надо хранить отдельно.

Здравствуйте, Cyberax, Вы писали:

C>GlebZ wrote:
>> C>Почему, просто записываем в OID физическую позицию в файле.
>> Не получится, индекс(а в особенности hash) как и страницы имеют
>> тенденцию менять свой размер. А следовательно — перемещаться. Так что
>> адрес по любому должен быть втой, или иной мере косвенным.
C>Индексы и блобы, естественно, надо хранить отдельно.
varchar тоже? Если строка перестает умещаться на странице, ее надо будет перемещать на ту, где уместится.

GlebZ wrote:
>> > C>Почему, просто записываем в OID физическую позицию в файле.
>> > Не получится, индекс(а в особенности hash) как и страницы имеют
>> > тенденцию менять свой размер. А следовательно — перемещаться. Так что
>> > адрес по любому должен быть втой, или иной мере косвенным.
> C>Индексы и блобы, естественно, надо хранить отдельно.
> varchar тоже? Если строка перестает умещаться на странице, ее надо будет
> перемещать на ту, где уместится.
varchar тоже. Причем можно использовать small string optimization — если
строка меньше N символов, то хранить ее в объекте, в противном случае —
в страничном хранилище.

Здравствуйте, Cyberax, Вы писали:

>> C>Индексы и блобы, естественно, надо хранить отдельно.
>> varchar тоже? Если строка перестает умещаться на странице, ее надо будет
>> перемещать на ту, где уместится.
C>varchar тоже. Причем можно использовать small string optimization — если
C>строка меньше N символов, то хранить ее в объекте, в противном случае —
C>в страничном хранилище.
Тады ты потеряешь больше производительности чем приобретешь. Обычно varchar-строк больше чем 50 процентов типов в траблице. Как результат тебе придется зачитывать от 2 до n страниц при чтении строки.

Здравствуйте, Cyberax, Вы писали:
C>varchar тоже. Причем можно использовать small string optimization — если
C>строка меньше N символов, то хранить ее в объекте, в противном случае —
C>в страничном хранилище.
Совершенно непонятно, как быть со строками, которые сильно короче N. Считаем потерю в (N-avg(len))*count допустимой?
Совершенно непонятно, как выбирать N. С учетом того, что маленькие значения будут приводить к очевидному оверхеду из-за доп. обращений (а лишние страничные обращения очень дороги), а большие — к потере пространства (и опять же лишним чтениям)...
Спор, конечно, в значительной мере теоретический, но на практике, насколько мне известно, все промышленные СУБД поддерживают record relocation. Я, честно говоря, не знаю, как удается держать RID стабильным при переносе записей со страницы на страницу, но скоро узнаю как с этим обстоит по крайней мере в MS SQL.

Здравствуйте, AndrewVK, Вы писали:

AVK>Хотелось бы обсудить как могла бы выглядеть современная настольная СУБД с учетом сужения класса решаемых задач и использования новых технологий и подходов.

Выглядит она примерно так: BerkleyDB
MySQL с InnoDB в качестве движка тоже подойдет — он умеет встраиваться inproc.

Более конкретный список вопросов:
AVK>1) in process или out of process?
inproc лучше по совокупности:
1) Нет потерь на межпроцессное взаимодействие (замедление до 10 раз при прокачке больших объемов данных)
2) Проще установка и администрирование приложения, компонентом которого является БД.

AVK>2) Физическая структура хранения на диске — алгоритмы, разбиение на файлы etc
Не принципиально. Варианты BTree используют все, кластерный индекс необходим но встречается в inproc-решениях редко, как бить на файлы в большинстве задач пофиг (чем тупее тем лучше — например, файл на таблицу). Еще прикольно, но не необходимо, иметь хэштаблицы. В BerkleyDB это все есть.

AVK>3) Описание метаданных
В заголовке файла таблицы.
Глобальные метаданные нафиг не нужны для встроенной в приложение БД. С ними ни жарко, ни холодно. Если очень надо, их можно XML-схемой описатьи рядом положить.

AVK>4) Способ формирования запросов
ISAM и интерпретатор тупого SQL или другого простого способа формировать запросы. Хранимые процедуры не нужны для inproc БД.

AVK>5) Контроль на уровне БД. Вобще разграничение функций между движком БД и прикладным кодом
Транзакции нужны. Доступ из множества процессов — бывает полезен, но можно обойтись без него.

AVK>6) Алгоримты деплоймента
На совесть программиста. Для встроенной БД, которую я здесь описываю, это несложно.

Собственно, берем BerkleyDB и начинаем радоваться жизни.

Здравствуйте, Sinclair, Вы писали:
S>Спор, конечно, в значительной мере теоретический, но на практике, насколько мне известно, все промышленные СУБД поддерживают record relocation. Я, честно говоря, не знаю, как удается держать RID стабильным при переносе записей со страницы на страницу, но скоро узнаю как с этим обстоит по крайней мере в MS SQL.
Возможно если представить строку как список, то головная часть состоящая из длины строки и начальноы части строки и ссылки на следующую часть строки. В зависимости от размера можно выделять различные блоки для хранения, максимальной котороя будет размер логической страницы принятой в БД. (головная часть может состоять из 30 символов).
Это так для примера.