Здравствуйте, Merle, Вы писали:
GZ>>Как результат, у нас нет уверености что мы сможем проиндексировать строки с неограниченной переменной длиной(как предлагал Sinclair). M>Во-первых Тоха не предлагал индексировать строки с различной переменной длинной, он предлагал их хранить и не париться над размером. Во-вторых я не вижу почему бы не индексировать только первый килобайт, если строка слишком большая, все равно ключ текст из середины сравнивать не умеет, и сравнение таких больших кусков очень большая экзотика...
Очень нехорошее решение тогда будет. Реализуешь решение, проходит год, и какой-то, обязательно наиболее важный клиент, начинает бочки гнать. Уже попадал на такое. Лучше уж сложнее, но чтобы потом исправить легко было, или сразу принять другое нормальное решение по реализации.
Здравствуйте, Merle, Вы писали:
GZ>>Для MSSQL varchar(max) image e.t.c. лежат в отдельных сегментах. Oracle умеет запись класть на несколько страниц. Разница есть. M>MSSQL тоже умеет, так что разницы нет. Это он специально для max-типов отдельное хранилище держит, что вообщем разумно и совершенно не мешает сделать так же. А вот если сумма обычных varchar-ов вылезает за размер страницы, то он совершенно спокойно резервирует дополнительную страницу под это дело и кладет хвостик туда, проставляя ссылочку.
Это 2005? Наконец-то.
M>Для начала вычеркиваем фразу про сложное администрирование (2005 express). >Потом вспоминаем, что задачи есть разные и записываем обратно.
? Я понимаю, что есть задачи, для которых юконом воспользоваться нельзя. Но при чем тут сложности с администрированием??? Или ты еще просто не использовал эту штуку?
M>Твое право, тогда эта тема не для тебя..
+1
Просто один знакомый этими вещами заморачивается, вот и заглянул.
M>Я вот сходу могу назвать где их много используют
FAT
M>На первом этапе, естественно, всегда выбирается готовое хранилище, чтобы не забивать себе голову мелочами, но когда выясняется, что готовое хранилище по каким-то параметрам не подходит приходится изобретать что-то свое... Вот каким это "свое" должно быть, и призван выяснить этот топик...
Боюсь, что "приходится изобретать что-то свое" прямо противоречит самому смыслу топика.
Ежели мы думаем над универсальностью, то нужна серьезная теоретическая база. На коленках это делать бесполезно. Труд огромный, а выигрыш -ну.... не такой уж огромный.
Здравствуйте, GlebZ, Вы писали:
GZ>>>Насчет функциональной формы подумай. Для меня частой задачей является задача сборки SQL запроса к БД(я работаю с сущностями которые могут изменяться в runtime). Что будет в случае функциональной формы?
AVK>>То же самое. Никакой разницы нет. Процедура перехода от декларативной формы к функциональной, по крайней мере для LINQ, проста как 3 копейки. GZ>Не-а. Ты не о том. Там редактирование различных запросов происходят по интересной схеме. Что то типа: GZ>
GZ>var v=from c in db.bla select c;
GZ>var v1=from c1 in db.bla1, c2 in v where c1.id=c2.id select c2;
GZ>var res=v1.ToList();
GZ>
GZ>У меня есть сомнения в оптимальности такого подхода. Или надо будет писать логический оптимизатор запросов.
И при чем здесь функциональная форма? Ты декларативную привел.
GZ>a)Логика выполнения запроса в режиме на каждый row — достаточно сложна. При использовании проекций, каждый раз нам придется его выполнять сново, или удерживать результаты части запроса. GZ>б) Или в запросе используются данные, получая key без данных, мы должны перечитывать их сново. GZ>Моя аргументация понятна?
Неа. Я уже совершенно потерялся и не могу понять, что ты хочешь доказать.
GZ>Вопрос: GZ>Примерная структура: GZ>1 уровень. Файл, сегменты, страницы. GZ>2 уровень. Типизированные данные, то бишь таблицы или отношения (должны иметь информацию о типах), индексы. GZ>3 уровень. Собственно он и есть конечная цель. Объекты и типизированные списки объектов(или tuples, по фиг). То есть то, чем пользуется пользователь.(должна иметь свою информацию о типах). GZ>Я правильно тебя понял?
Примерно.
AVK>>На хеше построен не join, а одна из его реализаций. GZ>Я этого и не скрывал
Я просто уточняю чтобы не было недопонимания.
AVK>>Тут не понял. При чем тут join и поиск в B+? Или ты предлагаешь хеш-индексы? Не думаю что это хорошая идея, даже в условиях PK фиксированного типа. GZ>Вот как раз в случае PK фиксированного типа, и хорошая идея. Одно время над этим бились все реляционщики, пытались построить hash эффективный для всех данных(проклиная SQL).
Не, проблема с хеш-индексом не в этом, а в том, что при модификации такого индекса он ведет себя не очень хорошо для того чтобы хранить его на диске. Иы можешь предложить алгоритм, чтобы количество дисковых операций при добавлении и удалении значений было сопоставимым с В+ индексом?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>> Ничто не мешает сделать многопользовательский доступ, но на уровнем удаленных методов. В большинстве случаев этого достаточно.
AVK>Знаешь, я на эту тему с тобой спорить не буду, потому как бесполезно. Можешь делать. Когда сделаешь, тогда и поговорим. А пока что мой опыт свидетельствует, что твои слова далеки от реальности.
Я считаю, что многопользовательский доступ только и всего. AVK>>>Т.е. данные внутри БД описываются системой типов самой БД, а прикладной код должен самостоятельно выполнять конверсию? И что мы выигрываем при этом?
S>> ООП подход.
AVK>??? Это конверсия типов то ООП?
Не совсем конверсия это раз, второе это неограниченность типа. У тебя есть кусок памяти в корый ты пихаешь, что угодно
S>> БД нужно только знание IComparer для индексов и длина записи. В большинстве случаев поля будут иметь неопределенный тип итд.
AVK>Ерунда. Поле в БД не может иметь неопределенный тип, хотя бы потому что на тип завязано построение В+ дерева.
Нужно только длинаключа и (смещения и длины полей для форирования ключа в индексе) длина записи.
Так или иначе нужна БД над которой легко делать ООП надстройку.
S>> Я смотрю на такую БД с точки зреня 1С, Паруса , акзапты.
AVK>А теперь погляди на заголовок темы.
Сделав БД тебе захочется от неё большего. Во всяком случае DBase вроде как развиваются.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
AVK>>Ерунда. Поле в БД не может иметь неопределенный тип, хотя бы потому что на тип завязано построение В+ дерева. S> Нужно только длинаключа и (смещения и длины полей для форирования ключа в индексе) длина записи.
Ага. А еще нужен хеш-код.
AVK>>А теперь погляди на заголовок темы. S> Сделав БД тебе захочется от неё большего.
Здравствуйте, AndrewVK, Вы писали:
GZ>>Не-а. Ты не о том. Там редактирование различных запросов происходят по интересной схеме. Что то типа: GZ>>
GZ>>var v=from c in db.bla select c;
GZ>>var v1=from c1 in db.bla1, c2 in v where c1.id=c2.id select c2;
GZ>>var res=v1.ToList();
GZ>>
GZ>>У меня есть сомнения в оптимальности такого подхода. Или надо будет писать логический оптимизатор запросов.
AVK>И при чем здесь функциональная форма? Ты декларативную привел.
Перепиши в функциональных терминах, будет то же самое. Проблема существует.
GZ>>a)Логика выполнения запроса в режиме на каждый row — достаточно сложна. При использовании проекций, каждый раз нам придется его выполнять сново, или удерживать результаты части запроса. GZ>>б) Или в запросе используются данные, получая key без данных, мы должны перечитывать их сново. GZ>>Моя аргументация понятна? AVK>Неа. Я уже совершенно потерялся и не могу понять, что ты хочешь доказать.
Что keyset не нужен.
GZ>>Вопрос: GZ>>Примерная структура: GZ>>1 уровень. Файл, сегменты, страницы. GZ>>2 уровень. Типизированные данные, то бишь таблицы или отношения (должны иметь информацию о типах), индексы. GZ>>3 уровень. Собственно он и есть конечная цель. Объекты и типизированные списки объектов(или tuples, по фиг). То есть то, чем пользуется пользователь.(должна иметь свою информацию о типах). GZ>>Я правильно тебя понял?
AVK>Примерно.
Отлично, сразу уточняющий вопрос:
При трансформации из записей таблиц в объекты с помощью операции проекции мы теряем информацию о том как этот объект живет на втором уровне. Как эту проблему решать?
AVK>Не, проблема с хеш-индексом не в этом, а в том, что при модификации такого индекса он ведет себя не очень хорошо для того чтобы хранить его на диске. Иы можешь предложить алгоритм, чтобы количество дисковых операций при добавлении и удалении значений было сопоставимым с В+ индексом?
Легко. Но надо сначало со структурой хранения. Хеш функция ведь должна по чему-то адресоваться.
Здравствуйте, mrozov, Вы писали:
M> Но при чем тут сложности с администрированием???
При том что в одних задачах можно обойтись без администрирования, а в других нет.
M> Или ты еще просто не использовал эту штуку?
M>Боюсь, что "приходится изобретать что-то свое" прямо противоречит самому смыслу топика.
Это каким образом?
M>Ежели мы думаем над универсальностью, то нужна серьезная теоретическая база.
Теоретическая база нужна всегда, вне зависимости от универсальности.
M>На коленках это делать бесполезно. Труд огромный, а выигрыш -ну....
Здравствуйте, GlebZ, Вы писали:
GZ>Очень нехорошее решение тогда будет.
Ничего нехорошего в нем нет.
GZ> Реализуешь решение, проходит год, и какой-то, обязательно наиболее важный клиент, начинает бочки гнать.
На что?
GZ>Лучше уж сложнее, но чтобы потом исправить легко было, или сразу принять другое нормальное решение по реализации.
Это и есть нормальное решение, здесь не надо сложнее. Для поиска по таким текстам B+ все равно бесполезен, здесь надо все равно движек поиска по блобам отдельно подключать. А ключа размером с килобайт для B+ — за глаза.
Здравствуйте, eao197, Вы писали: E>Интересно, а каким боком все это относится к моему сообщению?
Таким, что не надо сидеть и гадать, что дешевле — таблицы пересчета или там что еще. Ты все же сходи, почитай, как дяди делают. Твои рассуждения про замедление a[t[i]] по срввнению с a[i] — извини, лепет. Андрей говорит о том, что для выборки данных в твоем варианте надо сделать два обращения к диску — одно для t[i], и второе для a[t[i]]. E>К слову, моя система хранения как раз и создавалась для того, чтобы хранить объекты, динамически изменяющие свой размер (вроде std::string, std::vector, std::list и пр.).
Я мало знаю про твою систему хранения, зато знаю, что у Юкона мажорный номер версии равен 9. Эти парни уже пятнадцать лет полируют глюкало, основываясь на очень подробных данных о фактическом использовании, передовых теоретических разработках, и глубоких знаниях нижележащих технологий. Я слежу за эволюцией их стораджа начиная с версии 6.5. И я очень сомневаюсь, что кустарные поделки смогут сильно их превзойти на аналогичном поле.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали: AVK>Ну так зачем тогда в этом случае byte[], если есть соотв. тип? Но на самом деле я спрашивал про другое — возможно ли полностью отказаться от типов и динамических кортежей БД в пользу статической типизации?
Боюсь, что нет. Давай попробуем выполнить типичный запрос. Пусть это будет почтовая программа — ок, выведем список фолдеров по убыванию суммарного размера непрочитанных сообщений.
На SQL это что-то типа
select folder.*, u.unreadSize
from folder inner join
(select folderId, sum(size) as unreadSize from message where read=0 group by folderId) u on u.folderId = folder.id
Что мы видим? Мы добавили к кортежу folder вычисляемое поле. Причем воспользовались джойном и агрегатом. Можно было, конечно, вставить в кортеж настоящее поле и обновлять его — денормализовать базу. Но денормализаций на все случаи жизни не напасешься.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, GlebZ, Вы писали:
AVK>>И при чем здесь функциональная форма? Ты декларативную привел. GZ>Перепиши в функциональных терминах, будет то же самое. Проблема существует.
Может быть. Но какое это имеет отношение к функциональному стилю?
AVK>>Неа. Я уже совершенно потерялся и не могу понять, что ты хочешь доказать. GZ>Что keyset не нужен.
В ООБД? Возможно. А вот в реляционных иногда очень даже.
AVK>>Примерно. GZ>Отлично, сразу уточняющий вопрос: GZ>При трансформации из записей таблиц в объекты с помощью операции проекции мы теряем информацию о том как этот объект живет на втором уровне. Как эту проблему решать?
А вот именно этот вопрос я и задавал. Ответов я знаю несколько. Можно анализировать IL, можно отказаться от лямбд в операции проекции, можно использовать LINQ.
GZ>Легко. Но надо сначало со структурой хранения. Хеш функция ведь должна по чему-то адресоваться.
Здравствуйте, Sinclair, Вы писали:
S>Что мы видим? Мы добавили к кортежу folder вычисляемое поле.
Ты забыл о том, что мы говорим о настольной БД, а не о сервере. В настольной БД делать вычисления движком БД бессмысленно. И, в любом случае, что здесь изменит отсутствие типизации?
Здравствуйте, Sinclair, Вы писали:
S>Опять же упрощается реализация FK; заодно появляется возможность отказаться от произвольных JOIN и заставить джониться только по FK.
Это, имхо, скорее плохо, чем хорошо. Вот удобный синтаксис специально для join'ов по FK — это хорошо. Но ограниение...
Здравствуйте, Sinclair, Вы писали:
E>>Интересно, а каким боком все это относится к моему сообщению? S>Таким, что не надо сидеть и гадать, что дешевле — таблицы пересчета или там что еще. Ты все же сходи, почитай, как дяди делают. Твои рассуждения про замедление a[t[i]] по срввнению с a[i] — извини, лепет. Андрей говорит о том, что для выборки данных в твоем варианте надо сделать два обращения к диску — одно для t[i], и второе для a[t[i]].
В первый раз. При последующих обращениях t[i] уже будет в памяти. В продвинутом случае в специальном хранилище для t, в тривиальном случае -- в кэше БД.
Или ты знаешь БД, которые вообще без кэша работают?
E>>К слову, моя система хранения как раз и создавалась для того, чтобы хранить объекты, динамически изменяющие свой размер (вроде std::string, std::vector, std::list и пр.). S>Я мало знаю про твою систему хранения, зато знаю, что у Юкона мажорный номер версии равен 9. Эти парни уже пятнадцать лет полируют глюкало, основываясь на очень подробных данных о фактическом использовании, передовых теоретических разработках, и глубоких знаниях нижележащих технологий. Я слежу за эволюцией их стораджа начиная с версии 6.5. И я очень сомневаюсь, что кустарные поделки смогут сильно их превзойти на аналогичном поле.
Опаньки, а где я противопоставлял свою систему Юкону? Может напомнишь?
И по поводу кустарных поделок -- скажи это AndrewVK, а то он какую-то тему про кустарные настольные БД затеял, даже странно как-то.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>Ерунда. Поле в БД не может иметь неопределенный тип, хотя бы потому что на тип завязано построение В+ дерева. S>> Нужно только длинаключа и (смещения и длины полей для форирования ключа в индексе) длина записи.
AVK>Ага. А еще нужен хеш-код.
Вообще же можно делать БД как некое множество дженерик классов со всеми вытекающими. AVK>>>А теперь погляди на заголовок темы. S>> Сделав БД тебе захочется от неё большего.
AVK>Если захочется большего, я возьму MSSQL.
Она тебе не даст той свободы действий и скорости. А вот БД как абстрактный класс даст возможность применять намного больше фантазии и инструменты для отражения различных классов но такую БД.
Во всяком случае, такой подход для меня лично не является утопией.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Вообще же можно делать БД как некое множество дженерик классов со всеми вытекающими.
No comments.
S>Она тебе не даст той свободы действий и скорости.
Зато даст надежность, масштабируемость и предсказуемость.
S>А вот БД как абстрактный класс даст возможность применять намного больше фантазии и инструменты для отражения различных классов но такую БД.
Ага, а заодно потратить несколько лишних мегабаксов на проект.
S> Во всяком случае, такой подход для меня лично не является утопией.
S>select folder.*, u.unreadSize
S>from folder inner join
S>(select folderId, sum(size) as unreadSize from message where read=0 group by folderId) u on u.folderId = folder.id
S>
S>Что мы видим? Мы добавили к кортежу folder вычисляемое поле. Причем воспользовались джойном и агрегатом. Можно было, конечно, вставить в кортеж настоящее поле и обновлять его — денормализовать базу. Но денормализаций на все случаи жизни не напасешься.
Нас вообще-то должно волновать только "select folder.*, u.unreadSize". Остальное, то что внутри запроса, как я понимаю, дело компилятора запроса. Ну я виже два способа: первый — анонимные типы, второй — явно указанный тип, т.е:
p()
{
foreach (auto i in (select folder.*, u.unreadSize from ...))
{
//...
};
}
struct Row
{
Folder folder;
int unreadSize;
};
p()
{
foreach (auto i in (select new Row(folder, u.unreadSize) from ...))
{
m(i);
};
}
m(Row row) {...}
Имхо, оба способа должны присутствовать. И разве этого будет недостаточно?
Здравствуйте, AndrewVK, Вы писали:
AVK>Когда то давно, когда PC только появлялись, было такое явление как настольные СУБД. Потом их практически вытеснили SQL-сервера, и если они и есть где, то это в основном развитие старых продуктов. AVK>SQL-сервера это конечно здорово, однако по прежнему есть ряд применений, для которых их навороты не нужны, равно как не нужен оверхед, связанный с многопользовательским доступом и сложное администрирование. AVK>Хотелось бы обсудить как могла бы выглядеть современная настольная СУБД с учетом сужения класса решаемых задач и использования новых технологий и подходов. Более конкретный список вопросов: AVK>1) in process или out of process?
Желательны оба варианта. В первом варианте неплохо бы получить "сырой" интерфейс на какие-нить row set-ы, чтобы помимо декларативного SQL иметь возможность для императивных циклических алгоритмов.
AVK>2) Физическая структура хранения на диске — алгоритмы, разбиение на файлы etc
Ты будешь разрабатывать подобное?
В общем, мне нравится подход "больших" баз, типа MS SQL, когда я разные таблицы и даже разные колонки таблиц или части таблиц (индексы) могу распихивать по разным физическим файлам. Очень удобно порой, особенно насчет обсуждавшихся здесь "больших блобов". MS SQL заметно шустрее работает, когда большие колонки-блобы, которые не участвуют в подавляющем большинстве запросов, сидят в отдельном физическом файле (или даже диске).
AVK>3) Описание метаданных
Не понятен вопрос. Речь идет о возможном РАСШИРЕНИИ стандартных метаданных? (стандартные — ну там тип поля и ограничения, типа nullable, участие в индексе или ограничения в виде SQL)
AVK>4) Способ формирования запросов
Если in-proccess, то доп. через "сырые" интерфейсы доступа к данным.
AVK>5) Контроль на уровне БД. Вобще разграничение функций между движком БД и прикладным кодом
4 и 5 — это продолжение 1. Если in-proccess, то не имеет смысла сильно разграничивать полномочия, все равно хачить будут, лучше дать нормальные отлаженные интерфейсы для непосредственного доступа к данным. Если out-of-proccess, то разумеется, полное разграничение полномочий. Общение — только через запросы. Максимум, через некий аналог SQLDMO.
AVK>6) Алгоримты деплоймента
Не критично. Хотя, желательно, конечно, поддержка как стандартной инсталляхи, так и в виде DLL, для распространения как часть другого продукта.
не такой уж огромный.
Мы уже победили, просто это еще не так заметно...
1.1.4 stable rev. 510
