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

AVK>>Тут только надо помнить насколько это реализуемона практике.
S>Прекрасно реализуемо. Примеров тому довольно много

Какие то все примеры с бюджетами в сотни мегабаксов

AVK>>А что конкретно непонятно?
S>Что такое декларативный sql-like синтаксис я понимаю. А вот что такое "функциональный стиль" — не очень. Ты имеешь в виду линqовские лямбды/анонимные методы?

Как один из вариантов да. Точнее в LINQ есть и та и другая форма записи.

AVK>>Имеется ввиду произвольный формат строки без наличия соответствующего кортежа, описанного в терминах CLR.
S>А, вот это как раз возможно и допустимо. Проекции можно делать и игнорированием лишних полей (т.к. у нас нет узкого места — сети для перекачки лишнего трафика между клиентом и сервером);

Проблема не в трафике, проблема в контроле типов. Хотелось бы, если в запросе часть полей не используется, чтобы уже компилятор поймал за руку при попытке их использовать.

AVK>>Почему?
S>Это я про byte[]. Просто потому, что есть масса данных, которые иначе как в виде byte[] особо и не представишь. К тому же если есть охота хранить всякие пользовательские типы, то это 100% будет сделано через сериализацию и именно в byte[] переменной длины, т.к. в фиксировнную байт-раскладку умеют превращаться только структы.

Ну так зачем тогда в этом случае byte[], если есть соотв. тип? Но на самом деле я спрашивал про другое — возможно ли полностью отказаться от типов и динамических кортежей БД в пользу статической типизации?

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

E>Ну здесь есть разные мнения. Константин Книжник не зря в своих БД shadow copy использует. А он очень обстоятельно, насколько я заметил, к разработке подходит.
У Shadow Copy свои тараканы, например там минимальная гранулярность — страница, если я правильно помню... Хотя для настольных СУБД это может быть и не проблема. С частичным откатом там тоже проблема, если вдруг Save Point-ы понядобятся или, упаси байт, вложенные транзакции..

E>А Redo Only лог позволит транзакции откатывать?
Конечно.. Собственно WAL и Redo Only вовсе не взаимоисключающие понятия. Redo Only — это способ организаци лога WAL — способ работы с логом, означающий что преже чем попасть в основную базу данные обязательно должны оказаться в логе, что гарантирует восстановимость.
Соответственно, при Redo Only логе данные в базу до коммита никогда не попадут и для отката можно просто зачитать предыдущие данные из БД.
При коммите надо будет сбросить все данные в основное хранилище, если используется схема без check-поинтов, или сбросить на диск в лог и перенести в основное хранилище по чек-поинту.
Есть схема Undo Only, когда вся информация сразу пишется в БД, а в лог кладется предыдущая версия соответственно при откате все данные берутся из лога, но эта схема очевидно плоха тем, что в силу WAL данные должны писаться и в лог и в БД параллельно, а это ведет к большим нагрузкам на дисковую подсистему.
В серьезных СУБД сейчас как правило используется схема Undo/Redo. Запись лога представляет собой пару значений старая версия/новая версия. При этом есть возможность Lazy Writer-ом спокойно писать в базу, когда дисковая подсистема свободна и откатить/накотить данные в любой момент в случае сбоя.
Есть так же схема No Redo/No Undo, по сути это Redo Only, но все Redo данные держатся в памяти, а при коммите атомарно сбрасываются на диск в основное хранилище, главная проблема — обеспечить эту атомарность.. Ну и что делать если память закончилась.....

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

AVK>Нет, вот в insert я должен использовать то, что я упоминал под п.1.

Да на самом деле, на низком уровне БД это не суть важно. Важно, что есть некоторая порция данных, которую нужно записать.

AVK>В классических БД он обязан помещаться на одну страницу. Даже с учетом varchar. Единственное исключение это varcharmax и varbinarymax в последнем сиквеле.

Так ведь мы не про классическую БД до сих пор разговаливали

E>>Я говорил о том, что не нужно всю таблицу в память загружать.

AVK>Насчет лишней записи на диск возражений нет?

Я правда не знаю, откуда берется лишняя запись
Но из-за того, что shadow copy я сам не реализовывал, то настаивать не буду. Наверняка в реальной жизни все будет не так гладко.

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

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

То о чем говорил ты, похоже, можно сравнить с поведением серверов объектов.

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

GZ>Только это сильно усложнит систему хранения и операций с ним. Да и статистику, если будешь делать, также.
Да нет, не сильно... Это сильно усложняет всяческие навороенные оптимизации тепа Read Ahead-а и прочей лабуды, но для настольных БД это не нужно... А для простых вещей достаточно аккуратно реализовать работу со страницами данных, чтобы они имели возможность ссылаться друг на друга...

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

M>У Shadow Copy свои тараканы, например там минимальная гранулярность — страница, если я правильно помню... Хотя для настольных СУБД это может быть и не проблема. С частичным откатом там тоже проблема, если вдруг Save Point-ы понядобятся или, упаси байт, вложенные транзакции..

Да где же своих тараканов нет

M>Конечно.. Собственно WAL и Redo Only вовсе не взаимоисключающие понятия. Redo Only — это способ организаци лога WAL — способ работы с логом, означающий что преже чем попасть в основную базу данные обязательно должны оказаться в логе, что гарантирует восстановимость.
M>Соответственно, при Redo Only логе данные в базу до коммита никогда не попадут и для отката можно просто зачитать предыдущие данные из БД.
M>При коммите надо будет сбросить все данные в основное хранилище, если используется схема без check-поинтов, или сбросить на диск в лог и перенести в основное хранилище по чек-поинту.

Опаньки, оказывается, я использую у себя Redo Only лог

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

M>Есть так же схема No Redo/No Undo, по сути это Redo Only, но все Redo данные держатся в памяти, а при коммите атомарно сбрасываются на диск в основное хранилище, главная проблема — обеспечить эту атомарность..

ИМХО вероятностью сбоя в момент записи в случае сабжа можно пренебречь. Главное чтобы от программных ошибок БД не портилась.

M> Ну и что делать если память закончилась.....

Эксепшен и откат транзакции, что ж еще.

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

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

GZ>>Только это сильно усложнит систему хранения и операций с ним. Да и статистику, если будешь делать, также.
M>Да нет, не сильно... Это сильно усложняет всяческие навороенные оптимизации тепа Read Ahead-а и прочей лабуды, но для настольных БД это не нужно... А для простых вещей достаточно аккуратно реализовать работу со страницами данных, чтобы они имели возможность ссылаться друг на друга...
То бишь взять Oracle политику? Хотя они поддерживают строки на несколько страниц, строки все равно ограничены.
Попробуй подумать как сделать на varchar(max) B+ индекс?

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

GZ>То бишь взять Oracle политику?
Причем здесь Oracle? MS поступает точно так же, да и DB2 AFAIK...

GZ> Хотя они поддерживают строки на несколько страниц, строки все равно ограничены.
Ну да 2ГБ, если брать вариант MS...

GZ>Попробуй подумать как сделать на varchar(max) B+ индекс?
А зачем? В том же сиквеле длинна ключа ограничена 900-та байтами и ничего фатального в этом ограничении я не вижу.

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

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

GZ>>То бишь взять Oracle политику?
M>Причем здесь Oracle? MS поступает точно так же, да и DB2 AFAIK...
Для MSSQL varchar(max) image e.t.c. лежат в отдельных сегментах. Oracle умеет запись класть на несколько страниц. Разница есть.

GZ>>Попробуй подумать как сделать на varchar(max) B+ индекс?
M>А зачем? В том же сиквеле длинна ключа ограничена 900-та байтами и ничего фатального в этом ограничении я не вижу.
Как результат, у нас нет уверености что мы сможем проиндексировать строки с неограниченной переменной длиной(как предлагал Sinclair).

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

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

AVK>>>Тока с сабжем это немного общего имеет.
GZ>>Ну вот. Ограничиваем применимость сабжа?
AVK>Да, конечно. Невозможно сождать эффективную, простую и универсальную БД одновременно.
Зато можно к этому стремиться.

AVK>Если бы их не было вовсе ничего бы принципиально не изменилось, функциональная форма совсем не хуже.
Насчет функциональной формы подумай. Для меня частой задачей является задача сборки SQL запроса к БД(я работаю с сущностями которые могут изменяться в runtime). Что будет в случае функциональной формы?

AVK>Читайте доки, они рулез.
Ладно, тебя не переубедишь. Закончим пока данную тему.

GZ>>Зачем keyset? Зачем курсоры? Мы можем дать пользователю единую феню и не мучить его не особо нужным функционалом.
AVK>Затем что причины, почему ООБД до сих пор не получили распространения всем хорошо известны.
Отнюдь не в keyset. И лежат проблемы совершенно в другой плоскости. Проблему которую я описал показывает что все прекрасно решается как в функциональной форме(с делегатом) без возврата результата, так и через ienumerator взятый из List. Пользователь сам может решить и определить какой путь ему важен. Курсор как таковой мало интересен и малофункицонален и неудобен по сравнению с тем же IEnumerator.

Насчет ключей есть другая думка. В реляционных базах данных есть несколько типов join. Один из них построен на хеше. То есть, у нас есть два отношения. Один из них меньше другого. При join, база данных строит хеш-таблицу RID по маленькому списку, и затем просто находит значения для большого списка и соединяет. Очень действенный механизм. Поскольку уже никто не возражает что ключ должен быть глобально уникальным для БД, и синтетическим, то вполне можно использовать именно хеширование. Кроме того, это даст нам путь быстрого нахождение одного объекта.

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

M>Здравствуйте, Max404.NET, Вы писали:

MN>>а чем msde(2005express) не устраивает?
M>

M>однако по прежнему есть ряд применений, для которых их навороты не нужны, равно как не нужен оверхед, связанный с многопользовательским доступом и сложное администрирование

Для начала вычеркиваем фразу про сложное администрирование (2005 express).
Потом задумываемся про размеры оверхеда и его реальный вклад.
Потом вспоминаем про удобство единообразного подхода к работе с хранилищами данных.

Я лично пришел к выводу, что мне такая штука не нужна даже даром — потому как я буду сомневаться в стабильности ее работы и все равно выберу sql.

А вообще, такие вещи вроде давно уже есть, только мало кто их использует.

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


GZ>Для MSSQL varchar(max) image e.t.c. лежат в отдельных сегментах. Oracle умеет запись класть на несколько страниц. Разница есть.
MSSQL тоже умеет, так что разницы нет. Это он специально для max-типов отдельное хранилище держит, что вообщем разумно и совершенно не мешает сделать так же. А вот если сумма обычных varchar-ов вылезает за размер страницы, то он совершенно спокойно резервирует дополнительную страницу под это дело и кладет хвостик туда, проставляя ссылочку.

GZ>Как результат, у нас нет уверености что мы сможем проиндексировать строки с неограниченной переменной длиной(как предлагал Sinclair).
Во-первых Тоха не предлагал индексировать строки с различной переменной длинной, он предлагал их хранить и не париться над размером. Во-вторых я не вижу почему бы не индексировать только первый килобайт, если строка слишком большая, все равно ключ текст из середины сравнивать не умеет, и сравнение таких больших кусков очень большая экзотика...

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

E> Так вот, в ООБД различаются сервера объектов и сервера страниц. Сервер объектов при обращении к объекту манипулирует только объектами, абстрагируясь от их размещения на страницах БД. Соответственно, в лог записываются только значения объектов. Поэтому в логе есть только логическая информация.
Так работает WAL, да и в принципе логгирование. Собственно, в том числе, об эффективности такого подхода и не обязательности хранения физической структуры, и рассказывал Мохан в своем докладе про ARIES.

E> Сервера страниц при обращении к объекту возвращают все страницы, которые содержат данный объект. Соответственно, при изменении объекта назад приходят опять страницы и эти страницы сохраняются в логе. Поэтому в таком подходе в логе есть и информация о физической структуре БД. И падение такого лога -- это очень неприятная ситуация.
А вот так работает Shadow Copy...

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

AVK>>В классических БД он обязан помещаться на одну страницу. Даже с учетом varchar. Единственное исключение это varcharmax и varbinarymax в последнем сиквеле.

E>Так ведь мы не про классическую БД до сих пор разговаливали

Ну а коль так, тогда ты прежде должен описать зачем нам расцеплять строку на несколько страниц и насколько часто это будет происходить.

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

AVK>Ну а коль так, тогда ты прежде должен описать зачем нам расцеплять строку на несколько страниц и насколько часто это будет происходить.

Представим, что ты хочешь сохранить в своей настольной БД письмо. В виде чего ты его будешь сохранять?

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

AVK>>Да, конечно. Невозможно сождать эффективную, простую и универсальную БД одновременно.
GZ>Зато можно к этому стремиться.

Можно. Но среднюю точку все равно придется выбирать.

AVK>>Если бы их не было вовсе ничего бы принципиально не изменилось, функциональная форма совсем не хуже.
GZ>Насчет функциональной формы подумай. Для меня частой задачей является задача сборки SQL запроса к БД(я работаю с сущностями которые могут изменяться в runtime). Что будет в случае функциональной формы?

То же самое. Никакой разницы нет. Процедура перехода от декларативной формы к функциональной, по крайней мере для LINQ, проста как 3 копейки.

AVK>>Затем что причины, почему ООБД до сих пор не получили распространения всем хорошо известны.
GZ>Отнюдь не в keyset.

А я это и не говорил.

GZ> И лежат проблемы совершенно в другой плоскости.

А это пофигу. Прежде чем обсуждать аспекты ООБД, сначала надо обсудить необходимость в ООБД. Лично я пока более оптимальным выбором для сабжа считаю реляционный движек.

GZ> Проблему которую я описал показывает что все прекрасно решается как в функциональной форме(с делегатом) без возврата результата, так и через ienumerator взятый из List. Пользователь сам может решить и определить какой путь ему важен. Курсор как таковой мало интересен и малофункицонален и неудобен по сравнению с тем же IEnumerator.

IEnumerator это и есть курсор. Соответственно типизированный курсор, который предлагается, это IEnumerator<T>. Что касается ООБД, то вне наличия возможности хранения и индексирования составных типов данных с точки зрения дизайна лучше сделать меппер, нежели прошивать это в БД.

GZ>Насчет ключей есть другая думка. В реляционных базах данных есть несколько типов join. Один из них построен на хеше.

На хеше построен не join, а одна из его реализаций.

GZ> То есть, у нас есть два отношения. Один из них меньше другого. При join, база данных строит хеш-таблицу RID по маленькому списку, и затем просто находит значения для большого списка и соединяет.

Ага.

GZ> Очень действенный механизм. Поскольку уже никто не возражает что ключ должен быть глобально уникальным для БД, и синтетическим, то вполне можно использовать именно хеширование.

Хеш джойн? Ну да, его и сиквел в основном использует.

GZ> Кроме того, это даст нам путь быстрого нахождение одного объекта.

Тут не понял. При чем тут join и поиск в B+? Или ты предлагаешь хеш-индексы? Не думаю что это хорошая идея, даже в условиях PK фиксированного типа.

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

M>Для начала вычеркиваем фразу про сложное администрирование (2005 express).
Потом вспоминаем, что задачи есть разные и записываем обратно.

M>Потом задумываемся про размеры оверхеда и его реальный вклад.
Крепко задумываемся. А так же задумываемся где мы это дело используем.

M>Потом вспоминаем про удобство единообразного подхода к работе с хранилищами данных.
А так же про необходимость заниматься изнурительным OR маппингом, и вообще про проблемы связанные с поддержкой универсальности.

M>Я лично пришел к выводу, что мне такая штука не нужна даже даром — потому как я буду сомневаться в стабильности ее работы и все равно выберу sql.
Твое право, тогда эта тема не для тебя..

M>А вообще, такие вещи вроде давно уже есть, только мало кто их использует.
Пример?
Я вот сходу могу назвать где их много используют, причем каждый свое:
Omea Reader, Bat, Opera, Outlook... Почему бы тебе не посоветовать этим ребятам использовать SQL Express, Oracle Express или DB2 (тоже как-то на E)?

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

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

E>Представим, что ты хочешь сохранить в своей настольной БД письмо. В виде чего ты его будешь сохранять?

varcharmax

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

E>>Представим, что ты хочешь сохранить в своей настольной БД письмо. В виде чего ты его будешь сохранять?

AVK>varcharmax

Ну вот, имхо, ты сам и ответил на свой вопрос

Аналогичными примерами могут быть текстовые документы, которые хранятся в БД как последовательность параграфов (отдельный параграф как отдельный varchar).

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

AVK>Можно. Но среднюю точку все равно придется выбирать.
+1

AVK>>>Если бы их не было вовсе ничего бы принципиально не изменилось, функциональная форма совсем не хуже.
GZ>>Насчет функциональной формы подумай. Для меня частой задачей является задача сборки SQL запроса к БД(я работаю с сущностями которые могут изменяться в runtime). Что будет в случае функциональной формы?

AVK>То же самое. Никакой разницы нет. Процедура перехода от декларативной формы к функциональной, по крайней мере для LINQ, проста как 3 копейки.
Не-а. Ты не о том. Там редактирование различных запросов происходят по интересной схеме. Что то типа:

var v=from c in db.bla select c;
var v1=from c1 in db.bla1, c2 in v where c1.id=c2.id select c2;
var res=v1.ToList();

У меня есть сомнения в оптимальности такого подхода. Или надо будет писать логический оптимизатор запросов.


AVK>А это пофигу. Прежде чем обсуждать аспекты ООБД, сначала надо обсудить необходимость в ООБД. Лично я пока более оптимальным выбором для сабжа считаю реляционный движек.
Если ты где нибудь найдешь у меня упоминание о том что я предлагаю OOБД, я буду благодарен. Я только скромно спросил а будет ли наследование, и пока тему OODB вообще закрыл.

GZ>> Проблему которую я описал показывает что все прекрасно решается как в функциональной форме(с делегатом) без возврата результата, так и через ienumerator взятый из List. Пользователь сам может решить и определить какой путь ему важен. Курсор как таковой мало интересен и малофункицонален и неудобен по сравнению с тем же IEnumerator.

AVK>IEnumerator это и есть курсор. Соответственно типизированный курсор, который предлагается, это IEnumerator<T>. Что касается ООБД, то вне наличия возможности хранения и индексирования составных типов данных с точки зрения дизайна лучше сделать меппер, нежели прошивать это в БД.
a)Логика выполнения запроса в режиме на каждый row — достаточно сложна. При использовании проекций, каждый раз нам придется его выполнять сново, или удерживать результаты части запроса.
б) Или в запросе используются данные, получая key без данных, мы должны перечитывать их сново.
Моя аргументация понятна?

Вопрос:
Примерная структура:
1 уровень. Файл, сегменты, страницы.
2 уровень. Типизированные данные, то бишь таблицы или отношения (должны иметь информацию о типах), индексы.
3 уровень. Собственно он и есть конечная цель. Объекты и типизированные списки объектов(или tuples, по фиг). То есть то, чем пользуется пользователь.(должна иметь свою информацию о типах).
Я правильно тебя понял?

GZ>>Насчет ключей есть другая думка. В реляционных базах данных есть несколько типов join. Один из них построен на хеше.
AVK>На хеше построен не join, а одна из его реализаций.
Я этого и не скрывал

GZ>> Кроме того, это даст нам путь быстрого нахождение одного объекта.
AVK>Тут не понял. При чем тут join и поиск в B+? Или ты предлагаешь хеш-индексы? Не думаю что это хорошая идея, даже в условиях PK фиксированного типа.
Вот как раз в случае PK фиксированного типа, и хорошая идея. Одно время над этим бились все реляционщики, пытались построить hash эффективный для всех данных(проклиная SQL). Поскольку у нас фиксированный тип, у нас нет никаких противопоказаний. Сортировка по синтетическому ключу не нужна как таковая. SelectByKey — со сложностью O(1) будет не слишком отставать от SelectList(если они в кэше). А также мы сразу решим проблему быстрого join.