Здравствуйте, AndrewVK, Вы писали:
AVK>>>4) Допустимо ли требование первичного ключа типа GUID? V>>-
AVK>Традиционный вопрос — почему?
Да что-то не нравится его представление в дотнет. Нет чтобы сделать 2 лонга, там россыпь байт и прочего, и банальное сравнение не ахти какое быстрое.
Неужели Int64 мало? У нас же не будет распределенности, генерить ключи в одном месте будем.
AVK>>>1) Необходим ли SQL или любой другой текстовый декларативный язык запросов? V>>скорее да, чем нет... ибо удобно, да и опять же
AVK>В чем удобство?
Иметь возможность просмотреть данные отдельно от разрабатываемой системы.
V>>, возможно захочется тулзы делать.
AVK>Тому, кому захочется и флаг в руки.
В принципе я об этом и говорю. SQL можно как внешнюю либу прикрутить.
AVK>>>2) Что лучше — выборки или навигационный способ(курсоры). V>>Оба хороши, каждый для своего
AVK>Они взаимозаменямы, так что основным должен быть какой то один.
Если предоставлять доступ к кишкам, то стоит оптимизировать курсоры, ИМХО.
AVK>>>2) Допустим ли (и возможен ли?) полный отказ от нетипизированных данных (нетипизированных на уровне строки) при работе с БД? V>>трудный вопрос... А как насчет проекций и отчетов?
AVK>Проекции типизированные, отчеты — проблема тех, кто эти отчеты будет рисовать. Опять же — рефлекшен и полиморфизм никто не отменял.
Угу, как и IBindingList и т.д. Может быть. Разумеется, типизированность рулит и упрощает разработку этого дела.
AVK>>>Нужна ли поддержка автоматической реструктуризации данных при смене типов, встроенная в движек? V>>Вряд ли это легко без специального инструментария по смене типа. Т.е. мы поменяли имя и тип колонки/поля. Если эти действия не трекить, но непонятно, какая колонка куда поменялась...
AVK>Это элементарно решается привязыванием ко всем элементам метаданных уникального идентификатора. Если идентификатор другой, значит это другая колонка. Если нет — значит та же.
Я пока плохо представляю, как это будет работать вне специализированной системы разработки. Наверно у тебя сложилось некое представление об этом
AVK>>>Какие еще аспекты БД было бы интересно рассмотреть с точки зрения описанной задачи? V>>Политики владения/связи. Привязать сюда же GC для зависимых данных (почему бы и нет?)
AVK>Да вобщем особых проблем нет. Я как то даже в рпабочей системе такую штуку делал. Другое дело имеет ли смысл такое встраивать в БД?
Да. Абсолютно любая система с использованием БД обыгрывает всякие ситуации по владению-времени жизни связанных объектов. Иногда БД помогает (MS SQL начиная с 2000-го), иногда просто ограничивается накладыванием ограничений, и тогда разработчики сами делают одну и ту же тупую работу из проекта в проект...
Здравствуйте, AndrewVK, Вы писали:
AVK>Нафига оно мне? Построитель запросов для outlook выходит за рамки собственно БД. В отличие от внутрипрограммного доступа такая фича нужна далеко не всегда и сильно завязана на предметную область.
Я тебе предложил примерно показать область применения, ты показал. И тут оказывается что и это на данной шняге строить или невозможно, или неудобно. Нужна цель и требования. Тогда результат хотя бы кому-нибудь (кроме тебя, поскольку ты один сможешь подогнать задачу под свои требования) будет нужн.
AVK>>>>>Неа. Я уже совершенно потерялся и не могу понять, что ты хочешь доказать. GZ>>>>Что keyset не нужен. AVK>>>В ООБД? Возможно. А вот в реляционных иногда очень даже. GZ>>Только не keyset. Повторюсь, неэффективно.
И часто ты пользовался именно keyset?(это ведь только один из курсоров). Логика построения запросов для серверных курсоров достаточно сложная вещь. Не знаю как для MSSQL, но для Oracle — это совершенно отдельная математика. Для MSSQL наверное тоже, просто он делает это неявно.
AVK>Можешь повторяться сколько хочешь, только это не аргумент. На практике я с его использованием получал огромный выигрышь во времени реакции системы на действия пользователей, особенно когда в самом запросе есть тяжелые джойны.
А вообще, при тяжелых join именно keyset применим?
GZ>> К тому же еще я не уверен что при проекции вообще мы будем знать по какому id адресоваться. AVK>Тут все очень просто — надо проектировать запросы такими, чтобы знать все что необходимо. GZ>>Linq при сложной проекции функциклирует в read only. AVK>BLToolkit тоже. На реальных проектах это не сильно беспокоит. Пойми, я не хочу сейчас обсуждать OR mapper и мне не очень нравится идея встраивать его в БД. А вне меппера ни о каких модификациях проекций речи даже не идет.
GZ>>Фактически мы можем сохранять любой объект имеющий все not null поля(PK — также not null поле).
AVK>PK это readonly-поле. Что я точно знаю, так это то что ни в одной реальной задаче мне не понадобилось модифицировать значение первичного ключа.
+1
Еще любое аггрегируемое значение, также может быть read only.
GZ>> Но тут еще один вопрос. Информация о реальном объекте находится в запросе а не в типе, и зависит от запроса и метаданных. AVK>Только в том случае, если на уровне БД есть полиморфизм. В реляционных БД никакого полиморфизма нет.
Запрос подтвержен изменениям.
GZ>>
GZ>>select a.*, b.id from a outer join b on (a.id=b.id)
GZ>>
GZ>>И при этом b.id является not null полем, которое не всегда подгружается. Чую здесь будут проблемы в типах.
AVK>Какие? Ты пойми — задача создания нужного типа и задача формирования проекции на него целиком на плечах прикладного программиста. Вот он пусть и разруливает. Не надо пытаться наворотить на движек БД все возможные задачи — чем он проще, тем качественнее.
GZ>>1-32 — байт относительный адрес страницы и относительный адрес значения в странице. GZ>>Например, у нас 8 килобайтная страницы. Каждый физический указатель — 8 байт. На странице 8кБ/8=1024 значений.
AVK>Каких значенией? Хеш-кодов?
Нет. Первичный ключ — это логическое значение. Результат работы функции — физическое значение. То есть, на страницах должен быть список физических адресов.
GZ>> Как результат для получения значения в странице hash&0x3FF. AVK>Уже непонятно.
Это относительный индекс в массиве физических адресов.
GZ>> У нас осталось 22 бита с помощью которых мы будем адресовать страницы.
AVK>Еще менее понятно. Страница имеет свой собственный адрес, глобальный в пределах файла.
В данном случае нет. Это относительный адрес страницы. То есть номер страницы относительно первой в списке страниц на котором лежит данный индекс.
Вообще посмотри внимательно строение файлов MSSQL или Oracle. Лучше MSSQL. Он проще чем Oracle, и в нем нет ног от старых дисковых систем. Файл разделен на сегменты. Сегменты обеспечивают дефрагментированное чтение таблиц. Иначе будет диск головкой слишком часто чирикать. Сегменты разделены на страницы. Страницы это гранулярность чтения и нагрузки на память. То есть, тебе нужно будет удерживать в памяти именно страницы. Цифры что сегмент — 64кБ, а страница 8 кБ, я думаю надо будет оставить. Не спроста они такие.
GZ>>Однако при этом надо думать о несовпадении удаленных и созданных значений индексов. Вот на это, мы и употребим оставшихся 32 бита. То есть будет некоторый счетчик уникальности hash значений. Вероятность совпадения 1/(2*32) — практически космическая, в особенности для настольных систем. В данном случае, я бы подумал даже о том, как сохранить информацию о типе. Я думаю, она очень пригодится на программном уровне. Допустим, отнять биты у адресации, и вероятности.
AVK>Что то ты явно пропустил. И, главное — в хеше значения обязаны содержаться упорядоченно. Следовательно, если очередной PK нарушает порядок следования, следует переупорядочивать хеш на диске. Это очень дорого и как от этого избавиться ты так и не сказал.
Они не должны лежать упорядоченно. Это им не нужно. Это синтетический ключ, поиска по диапазону к нему не нужен, join в котором нужна сортировка также нам не нужны. Так зачем?
GZ>>Что касается создания, удаления. В данном случае предлагается использовать такой же механизм, как и для страниц таблиц. AVK>Нельзя. В В+ дереве, в чем его прелесть, упорядоченность поддерживается автоматически. Использовать расщепление страниц для модификации хеш-таблицы не выйдет — там нужна линейная упорядоченность. Либо придется хранить в памяти соответствие между страницами хеш-индекса и порядком следования, что не очень здорово.
Повторюсь, упорядочивать значения нам не нужно. А не нужно балансировать хеш. Заполненность полная. У нас либо хватает значений, либо не хватает. Если нам нужно новое значение, то в bitmap мы находим страницу обозначенную что у нее есть пустой слот, находим ее и сохраняем. Если таковой нет, то добавляем новую страницу в индекс. Если у нас полностью заполнена страница, то мы добавляем изменяем bitmap и добавляем к транзакции. Вероятность добавления к транзакции 1/1024.
AVK>Разница самая обыкновенная — для того чтобы работала хеш-таблица хеши должны быть линейно упорядоченны. Как обеспечивается это в памяти я знаю, а вот как обеспечить это на диске пока не ясно.
Ты можешь организовать диапозоны хэшей на определенных страницах. Внутри которой хэши отсортированы.
Начинается на уровне четный нечетный
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Merle, Вы писали:
GZ>> А то что стрельнет, по закону подлости — обязательно. M>Приведи мне пример задачи, где пригодился бы поиск по B+ с ключем длиннее килобайта.
Outlook. Письма, задачи e.t.c.
Здравствуйте, GlebZ, Вы писали:
GZ>Я тебе предложил примерно показать область применения, ты показал. И тут оказывается что и это на данной шняге строить или невозможно, или неудобно.
Пока еще ничего не оказалось.
GZ> Нужна цель и требования.
Ага, ты еще ТЗ попроси. Если бы у меня была четкая картина задачи, я бы тут философские разговоры не разводил. Все что я могу на данный момент сказать, я уже сказал. Цели и требования точно так же уточнять надо. На данном этапе встраивать в движек универсальные текстовые запросы, только потому что есть одна весьма специфичная задача, мне не кажется целесообразным.
GZ>>>Только не keyset. Повторюсь, неэффективно. GZ>И часто ты пользовался именно keyset?
На десктопе часто.
GZ>(это ведь только один из курсоров). Логика построения запросов для серверных курсоров достаточно сложная вещь.
Я серверные не использую, я использую клиентские. И здесь речь, ты еще не забыл, о настольной БД. Проблемы серверных БД меня в данном контексте не волнуют, особенно проблемы многопользовательского доступа.
GZ>А вообще, при тяжелых join именно keyset применим?
Еще как. А что, у тебя с этим какие то проблемы?
AVK>>Только в том случае, если на уровне БД есть полиморфизм. В реляционных БД никакого полиморфизма нет. GZ>Запрос подтвержен изменениям.
Каким?
GZ>>>1-32 — байт относительный адрес страницы и относительный адрес значения в странице. GZ>>>Например, у нас 8 килобайтная страницы. Каждый физический указатель — 8 байт. На странице 8кБ/8=1024 значений.
AVK>>Каких значенией? Хеш-кодов? GZ>Нет. Первичный ключ — это логическое значение. Результат работы функции — физическое значение. То есть, на страницах должен быть список физических адресов.
Физических адресов чего? Записей в кластерном индексе? Тогда что мы увидим в прикладном коде?
AVK>>Еще менее понятно. Страница имеет свой собственный адрес, глобальный в пределах файла. GZ>В данном случае нет.
Значит фиговый случай, поскольку несовместим с остальными данными.
GZ>Вообще посмотри внимательно строение файлов MSSQL или Oracle. Лучше MSSQL. Он проще чем Oracle, и в нем нет ног от старых дисковых систем. Файл разделен на сегменты. Сегменты обеспечивают дефрагментированное чтение таблиц. Иначе будет диск головкой слишком часто чирикать. Сегменты разделены на страницы. Страницы это гранулярность чтения и нагрузки на память. То есть, тебе нужно будет удерживать в памяти именно страницы. Цифры что сегмент — 64кБ, а страница 8 кБ, я думаю надо будет оставить. Не спроста они такие.
Все это здорово, но я что то не улавливаю какое это имеет отношение к разговору.
AVK>>Что то ты явно пропустил. И, главное — в хеше значения обязаны содержаться упорядоченно. Следовательно, если очередной PK нарушает порядок следования, следует переупорядочивать хеш на диске. Это очень дорого и как от этого избавиться ты так и не сказал. GZ>Они не должны лежать упорядоченно. Это им не нужно.
Да, тяжело тебя понять. Попробуем сделать еще одно предположение — ты хочешь использовать в качестве ключа физический адрес записи в кластерном индексе? А что тогда делать при расщеплении его страницы?
GZ> Это синтетический ключ, поиска по диапазону к нему не нужен, join в котором нужна сортировка также нам не нужны. Так зачем?
Что зачем? Зачем упорядоченно? Затем, что хеш-функция должна при помощи простых арифметических операций вычислить адрес записи.
Вобщем я не могу понять, что за алгоритм ты имеешь ввиду. Попробуй объяснить его поподробнее.
Здравствуйте, GlebZ, Вы писали:
M>>Приведи мне пример задачи, где пригодился бы поиск по B+ с ключем длиннее килобайта. GZ>Outlook. Письма, задачи e.t.c.
Ты хорошо представляешь что такое B+? При большем размере ключа B+ уже не эффективен.
И что ты собрался искать в письмах по ключам такого размера?
Еще раз говорю, бля поиска в больших текстах, совсем другие механизмы нужны...
Здравствуйте, Serginio1, Вы писали:
S>Ты можешь организовать диапозоны хэшей на определенных страницах. Внутри которой хэши отсортированы. S> Начинается на уровне четный нечетный
Могу. Но вопрос остается прежним — что делать при модификациях?
Здравствуйте, vdimas, Вы писали:
V>Да что-то не нравится его представление в дотнет.
Это несерьезно.
V> Нет чтобы сделать 2 лонга, там россыпь байт и прочего, и банальное сравнение не ахти какое быстрое.
На уровне БД можно использовать что угодно, а GUID формировать только на уровне выдачи результата.
V>Неужели Int64 мало?
Мало. Потому что GUID обладает замечательной особенностью — отпадает необходимость в генераторах или автоинкременторах в движке БД и операциях его считывания после добавления записи. Грубо говоря — я могу знать PK объекта даже не обращаясь к БД.
AVK>>Это элементарно решается привязыванием ко всем элементам метаданных уникального идентификатора. Если идентификатор другой, значит это другая колонка. Если нет — значит та же.
V>Я пока плохо представляю, как это будет работать вне специализированной системы разработки. Наверно у тебя сложилось некое представление об этом
Так и будет. Объявляем тип, регистрируем его в БД. Что там нужно специализированного? Ну разве что план запроса посмотреть.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>>Ты можешь организовать диапозоны хэшей на определенных страницах. Внутри которой хэши отсортированы. S>> Начинается на уровне четный нечетный
AVK>Могу. Но вопрос остается прежним — что делать при модификациях?
Перераспределение при переполнении но только части страниц. Хотя индекс по хэшам длинных индексов имхо выгодней, а для небольших по размеру ключей выигрыш для хэш таблиц небольшой , учитывая кэширования верхних страниц индекса.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
AVK>>Могу. Но вопрос остается прежним — что делать при модификациях? S>Перераспределение при переполнении но только части страниц.
А что делать с внешними ключами?
S> Хотя индекс по хэшам длинных индексов имхо выгодней, а для небольших по размеру ключей выигрыш для хэш таблиц небольшой , учитывая кэширования верхних страниц индекса.
Он выгоднее в памяти. А вот работающий алгоритм для диска я пока не услышал.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>Могу. Но вопрос остается прежним — что делать при модификациях? S>>Перераспределение при переполнении диапозона но только части страниц.
AVK>А что делать с внешними ключами?
А причем тут они???? Контроль ссылочноти как то не связан с поиском по ПК.
Самый простой способ Сделать индекс типа, ПK,IDТаблицы,ПКвтаблице. И он как то не привязан к к организации хранения первичного ключа.
S>> Хотя индекс по хэшам длинных индексов имхо выгодней, а для небольших по размеру ключей выигрыш для хэш таблиц небольшой , учитывая кэширования верхних страниц индекса.
AVK>Он выгоднее в памяти. А вот работающий алгоритм для диска я пока не услышал.
Как это не услышал??? Хотя я и не стронник применения Хэш таблиц для ПК, но реально они существуют и используются и достаточно хорошо описаны.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Ага, ты еще ТЗ попроси.
ТЗ нет. А вот vision — с удовольствием бы. Тогда было бы более понятно что строим и с кем конкурируем. И вообще границы задачи.
GZ>>>>Только не keyset. Повторюсь, неэффективно. GZ>>И часто ты пользовался именно keyset? AVK>На десктопе часто.
Никогда. Лучше я десять раз перекачаю лишние данные, чем каждый раз обращаться к серваку. А десктопами, особо не занимался.
GZ>>(это ведь только один из курсоров). Логика построения запросов для серверных курсоров достаточно сложная вещь. AVK>Я серверные не использую, я использую клиентские. И здесь речь, ты еще не забыл, о настольной БД. Проблемы серверных БД меня в данном контексте не волнуют, особенно проблемы многопользовательского доступа.
Проблема серверных курсоров лежит в многопользовательском доступе, и только в нем. И больше нигде. Поэтому предлагаю размыть разницу между серверным и клиентским курсором. Тем более что у нас именно встроенная система.
GZ>>А вообще, при тяжелых join именно keyset применим? AVK>Еще как. А что, у тебя с этим какие то проблемы?
Я просто не понял, если ты держишь у себя результат join'a, то есть проекции от него, то каким образом ты его адресуешь? Или это только когда проекция одной таблицы?
AVK>>>Только в том случае, если на уровне БД есть полиморфизм. В реляционных БД никакого полиморфизма нет. GZ>>Запрос подтвержен изменениям. AVK> Каким?
На заключительном этапе мы пытаемся отрефакторить новое приложение так, чтобы пользователь хотя бы чайку при запросе не успел выпить. А достигается это рефакторингом запросов и схемы. А менять приложение в таком случае, не очень приятное занятие.
AVK>Вобщем я не могу понять, что за алгоритм ты имеешь ввиду. Попробуй объяснить его поподробнее.
OK. Несколько прописных истин приведу, для большего понятия:
1. Primary Key — это система получения физического адреса записи по некоторому значению. Физический адрес может быть изменен(например при restore backup, или shrink), поэтому он ни в каком виде не предоставляется пользователю.
2. Нам не нужно какое-то упорядочение ни логических адресов(значений primary key) ни физических. Кластерный индекс по ним не строится(ну можем представить смысл в кластерном индексе основанном на guid). Для кластерного индекса пользователь может использовать любой свой, основанный на B+ индексе.
3. Типов хешей, я знаю по крайней мере 3(это не по функциям, а по типам алгоритмов). Сказать как они называются не могу, давно серьезно этим занимался, если что, ради буквы закона, можно спросить в алгоритмах. Первый — когда работаем по косвенной адресации. Косвенная адресация массива — это простейший тип, h(i)=i. Второй, это когда мы в случае коллизий кладем значение где-то возле коллизии, третий — когда мы в случае коллизии продолжаем хеширование пока не найдем пустое место(собственно, именно этот тип реализован в Net насколько я помню). В данном случае — это первый тип. У нас в значении лежит относительный адрес в хеш-таблице по которому мы можем найти физический. То есть по хеш-функция h(i)=относительный_адрес_страницы+относительный_адрес_значения_физического_указателя_на_строку.
4. Страницы и сегменты адресуются тремя способами. Первый способ — страницы одной таблицы или индекса связаные как двухсвязный список. Мы через IAM находим первую блок, и далее по списку. Второй способ — B tree что-то типа здесь. Третий способ — прямая адресация.
5. Для нахождения нужного row, a) мы получили значение primary key и имя таблицы(или индекса).
b) Нашли в IAM страницу с началом списка hash-таблицы. (1 чтение, скорее всего из буфера)
c) По хеш функции высчитали относительное положение в таблице (относительное положение страницы и относительное положение в страницу).
d) По дереву дошли до нужной страницы.(1<x<n чтений в глубину, вероятнее всего из кэша, и то что 1).
e) Прочитали 8 байтовое значение.
f) Относительно данного значения вычислили страницу где находится данная строка
j) Прочитали страницу
h) Пользуясь списком row в конце страницы и физическим адресом, нашли строку, и ее вернули
6. bitmap — это очень простой индекс. То есть, каждое значение — это либо установленный бит, либо сброшенный бит. Биты пакуются в байты, то есть каждый байт — это 8 значений.
7. Мы содержим в заголовке первой страницы bitmap index с свободными страницами. Ну например, если бит сброшен то в странице есть пустые элементы в которые можно вставить. Ну например, 11101101 — на 4 и 7 страницу можно вставить значение. После этого при вставке находим 4 страницу, находим пустое значение, вставляем физический адрес создаваемой строки, и возвращаем относительный адрес данного элемента который в дальнейшем будет первичным ключом для данной строки. Соответсвенно, смотрим есть ли еще свободные элементы. Если элементов нет, то мы устанавливаем бит, что данная страница полностью занята.
8. Допустим мы отведем в заголовке под индекс — 128 байт. Как результат, у нас получится что индекс управляет 128*8=1024 страницы. Каждая страница содержит — 1024 физических адреса. То есть, с помощью 128 байт мы держим 1 миллион записей. Если мы переходим через 1 миллион записей, то создаем еще битмап индекс в 128 байт и привязываем его через двухстороннюю очередь.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>Могу. Но вопрос остается прежним — что делать при модификациях? S>>Перераспределение при переполнении но только части страниц. AVK>А что делать с внешними ключами?
Внешние ключи адресуются по primary key. Рельные физические адреса надо изменять в связанных индексах по любому.
S>> Хотя индекс по хэшам длинных индексов имхо выгодней, а для небольших по размеру ключей выигрыш для хэш таблиц небольшой , учитывая кэширования верхних страниц индекса. AVK>Он выгоднее в памяти. А вот работающий алгоритм для диска я пока не услышал. здесь
V>> Нет чтобы сделать 2 лонга, там россыпь байт и прочего, и банальное сравнение не ахти какое быстрое.
AVK>На уровне БД можно использовать что угодно, а GUID формировать только на уровне выдачи результата.
+1
V>>Неужели Int64 мало?
AVK>Мало. Потому что GUID обладает замечательной особенностью — отпадает необходимость в генераторах или автоинкременторах в движке БД и операциях его считывания после добавления записи. Грубо говоря — я могу знать PK объекта даже не обращаясь к БД.
Собсно, я для этого использую счетчики в программе. И я тоже знаю ПК объекта заранее и даже могу понасоздавать в памяти графы связанных объектов и затем в один присест сохранить. Думаешь, дело упирается в генерацию ПК???
В одном из проектов, когда я оптимизировал ПК, то бишь уменьшил где только это возможно ширину данных (с 32 до 16 или даже 8 бит) у меня быстродействие базы выросло более чем вдвое. Ты же не забывай, что таблицы, которые хранят наибольшее число строк (сотни тысяч и миллионы), обычно представляют из себя некие "движения", и в этих данных половина полей — значения ПК связанных (справочних и не только) таблиц. Т.е. одно дело, когда у меня в строке данных примерно 8 ключей с типами от int8 до int32, и другое дело — 8 гвидов...
Для того, чтобы не страдать переполнением малоразрядных счетчиков, я использую кеш удаленных ключей, для повторного их использования на новых объектах. В общем, все ради сужения типа, представляющего ключ, ибо это в разы повышает эффективность.
Здравствуйте, GlebZ, Вы писали:
GZ> Для кластерного индекса пользователь может использовать любой свой, основанный на B+ индексе.
Так ли велик будет выигрыш от приседания вокруг хэш-таблицы, если все равно надо поддерживать два типа индексов, причем хэш-таблица какая-то не очень тривиальная получается?
Здравствуйте, stalcer, Вы писали:
S>Нас вообще-то должно волновать только "select folder.*, u.unreadSize".
Нет, это волнует прикладного программиста, который будет пользовать эту гипотетическую БД. S>Остальное, то что внутри запроса, как я понимаю, дело компилятора запроса.
А разработчиков БД как раз это и волнует. Точнее, волнует вообще возможность type inference. S>Ну я виже два способа: первый — анонимные типы, второй — явно указанный тип, т.е:
Это все очень хорошо, но непонятно, как будет работать на практике. Никто не собирается делать еще один компилятор C#-подобного языка. Все должно работать по-настоящему.
Если отказаться от type inference, то все запросы будут возвращать что-то приводимое к IEnumerable<T>, где T — один из хранимых в БД типов.
Если не отказываться, то запросы должны будут возвращать что-то типа дотнетовых датасетов (т.е коллекций строк, каждая из которых суть список пар ключ/значение).
S>Имхо, оба способа должны присутствовать. И разве этого будет недостаточно?
Это ты здорово придумал. Вот только я не очень понял, на каком это языке. C# такого пока не позволяет. Я не очень внимательно слежу за тем, что будет позволено в C# 3.0.
В целом мне, конечно, идея нравится. Проблема только в том, что для обеспечения второго способа (точный именованный тип) тебе фактически нужен первый (а потом ты просто перекладываешь данные из анонимного типа в именованный путем явного вызова конструктора).
Вот такая вот петрушка. Надо копать в анонимные типы в третьем шарпе, чтобы понять, что там вообще можно сделать.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, stalcer, Вы писали: S>Это, имхо, скорее плохо, чем хорошо. Вот удобный синтаксис специально для join'ов по FK — это хорошо. Но ограниение...
Я просто очень давно не видел других джойнов. Разве что в отчетах... Но там обычно вообще такая дикость присутствует, что мама дорогая...
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>Могу. Но вопрос остается прежним — что делать при модификациях? S>>Перераспределение при переполнении но только части страниц.
AVK>А что делать с внешними ключами?
S>> Хотя индекс по хэшам длинных индексов имхо выгодней, а для небольших по размеру ключей выигрыш для хэш таблиц небольшой , учитывая кэширования верхних страниц индекса.
AVK>Он выгоднее в памяти. А вот работающий алгоритм для диска я пока не услышал.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, GlebZ, Вы писали:
GZ>> Для кластерного индекса пользователь может использовать любой свой, основанный на B+ индексе. M>Так ли велик будет выигрыш от приседания вокруг хэш-таблицы, если все равно надо поддерживать два типа индексов, причем хэш-таблица какая-то не очень тривиальная получается?
Во первых я там ошибся, должно быть B+ дерево.
А выйгрыш получится достаточно большой. У нас не будет надобности хранить значения от primary key. То есть в случае 8 байтового значения индекс будет в два раза меньше. В случае guid'а еще больше. Как результат, у нас увеличивается вероятность что на мелких таблицах(коих иногда очень даже много) мы весь primary key уместим на одной странице. Это должно снизить нагрузку на кэш. Во вторых, у нас в отличие от B дерева — нет надобности сравнивать значения. То есть в случае если все лежит в кэше, поиск значения мгновенный. Логарифметическая сложность поиска сохраняется, только в отличие от Nlog(N) получается log(N). Но опять же, повторюсь, при полном сканировании индекса, он как минимум в два раза меньше. Что должно повлиять на быстроту join. Ну и еще мы получаем практически готовый эффективный join. Надо просто добавить сравнение.
У нас же не будет распределенности, генерить ключи в одном месте будем.
(почему бы и нет?)
Каким?
Мы уже победили, просто это еще не так заметно...
1.1.4 stable rev. 510
