?

Log in

No account? Create an account
 
 
13 Декабрь 2007 @ 16:50
Реляционные СУБД и TrackStudio  
kranov пишет, что наш способ хранения длинных строк в СУБД (с разбиением строк на кусочки и сборкой через SQL при необходимости) есть кривизна и об этом стоит помалкивать, а не рассказывать как о преимуществе TrackStudio при сравнении с JIRA:

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

Проблема тут в том, что реляционные СУБД вообще плохо подходят для написания приложений типа TrackStudio по принципиальным соображениям:

  • Реляционные СУБД подразумевают работу с множествами записей. Т.е. берем множество этих записей, еще вот этих, находим их пересечение, а потом вот так фильтруем и сортирует. В итоге у нас 1 сложный запрос, который возвращает 1000 записей, реляционные СУБД отлично справляются с такого рода задачами.
  • Есть большой класс проблем, которые плохо/неэффективно реализуются за счет операций над множествами. Разработчики реляционных СУБД не пытаются их решать, даже в нестандартных расширениях:
  • работа с иерархиями: как получить все подзадачи (рекурсивно) данной задачи,  все вышестоящие задачи ? Из всех популярных РСУБД только в ORACLE есть start with/connect by, работающий к тому же очень медленно.
  • в большинстве РСУБД крайне примитивная security, часто она просто игнорируется пользователями и разработчиками приложений. Например, нельзя ограничивать доступ пользователей к данным на уровне отдельного поля или отдельной строки таблицы: нельзя запретить пользователю A редактировать имя директора компании Б.
Решение обоих этих проблем (внутри СУБД или во внешних приложениях) требует другого паттерна доступа к данным: вместо обработки больших множеств нужна быстрая навигация по данным и быстрая обработка простых запросов. Большинство РСУБД делают то и другое крайне неэффективно.
Неадекватность реляционной модели для решения этих задач не позволяет решить эти задачи в рамках самой СУБД и означает невозможность решить эти задачи в рамках приложения, опирающегося на СУБД. Тут не помогает атомарности транзакций или поддержка гигабайтов данных - без кеша уровня приложения РСУБД за десятки тысяч долларов жутко тормозят на объемах, с которыми легко справляется Excel. А если мы начинаем делать кеш приложения - нам самим нужно думать о параллельном доступе к этому кешу, о состоянии кеша после облома транзакции, о синхронизации кешей 2-х экземпляров приложения в кластере и т.п.

Вывод: невозможность нормально хранить длинные строки в ORACLE - это еще цветочки. Для решения 90% задач из JIRA most popular issues реляционные СУБД вообще не подходят и нужно реализовывать другие методы доступа к данным поверх РСУБД. То, что большинство багтрекеров имеет "плоскую" организацию и поддерживает только самые простые правила доступа - это не потому что не надо никому (практика показывает, что как раз надо), а потому что разработчики таких систем ограничены особенностями реляционной модели, а их преодоление требуют весьма значительных усилий.

Маленький пример из другой области: у кассетных магнитофонов и DVD-плееров пульты почти одинаковые, но на пульте магнитофона нет кнопок перехода к следующей/предыдущей записи.  Хотя на первый взгляд пульты кажутся очень похожими, это серьезное внутреннее ограничение магнитофонов, а не досадная недоработка разработчиков пульта.
 
 
 
(Удалённый комментарий)
Макс Васенковwinzard on Декабрь, 14, 2007 04:33 (UTC)
Вообще Макс зря распинался и навлек на себя гнев общественности. Достаточно было сказать, что ДЛЯ НАШИХ задач реляционная СУБД, по сути, вообще не нужна. А используется она как НОК всех остальных способов хранения.
(Удалённый комментарий)
(no subject) - winzard on Декабрь, 15, 2007 08:32 (UTC) (Развернуть)
(no subject) - winzard on Декабрь, 15, 2007 08:33 (UTC) (Развернуть)
(Удалённый комментарий)
(no subject) - winzard on Декабрь, 17, 2007 19:22 (UTC) (Развернуть)
Максим Крамаренкоmaximkr on Декабрь, 13, 2007 17:43 (UTC)
>> только в ORACLE есть start with/connect by, работающий к тому же очень медленно

> Насчёт медленно -- ели уху.
> Насчёт остальных -- делается криво, ибо это нарушение реляционной модели. Что, если будет цикл? Но
> делается: для MS SQL пишите SP, которая вставляет во временную таблицу.
> Если считаете, что очень умны и можете осчастливить мир -- качайте сорцы MySQL и пишите иерархические
> запросы. Подозреваю, что не сможете сделать лучше Оракла. Причины тут философские.

Все равно это очень тормозно, проверяли. Первые версии TrackStudio как раз использовали ORACLE 8i и start with/connect by. С более простой security, чем сейчас, вывод 5-10 задач при 2000 задач в базе занимал порядка 2-3 минут на P3-750. Нынешние версии не требуют ORACLE и работают куда быстрее даже на миллионе задач :-)

MySQL тут не поможет, проблема не в особенностях конкретной СУБД.

>> большинстве РСУБД крайне примитивная security, ... Например, нельзя ограничивать доступ
>> пользователей к данным на уровне отдельного поля

> Брехня. Все нормальные поддерживают, ибо стандарт.

Имеется в виду создание view вытягивающего только разрешенные поля и последующая работа через этот view ?

>> или отдельной строки таблицы
> Это расширение SQL стандарта. Есть Secure Oracle, он даже сертифицирован. Там это есть.

А где можно подробности почитать о возможностях. Google о "secure oracle" находит не слишком много.

>> невозможность нормально хранить длинные строки в ORACLE
> БЛОБы никто не отменял. Вероятно, хотите сказать не "хранить", а "искать" -- ну так, есть
> мощные отдельные поисковые сервера.

Не, именно хранение. BLOB-ы в ORACLE весьма кривые, вот что народ из Atlassian пишет
http://www.atlassian.com/software/jira/docs/v3.6.5/databases/oracle.html
Мой опыт работы с этим был примерно аналогичным, поэтому мы с BLOB-ами решили изначально не связываться.

(Удалённый комментарий)
(no subject) - maximkr on Декабрь, 15, 2007 09:34 (UTC) (Развернуть)
(Удалённый комментарий)
Anatoly Levenchukailev on Декабрь, 13, 2007 22:18 (UTC)
Мы сажали Коммунивер на Постгресс и Оракл, наелись реляционности по самое не балуйся. Поэтому полностью подтвержу: вся эта реляционность выходит боком, ежели природа данных не таблична.

P.S.
Я, кстати, не исчез. Просто уже несколько дней физически не нахожусь около компьютера в приемлемое для разговоров время. Конец года, нарастающее сумасшествие вокруг, толстые деды Лайны совсем затолкали. Я попробую завтра утром связаться.
Максим Крамаренкоmaximkr on Декабрь, 13, 2007 23:03 (UTC)
Хорошо, жду :)
Максим Крамаренкоmaximkr on Декабрь, 13, 2007 23:03 (UTC)
Я решил более подробно описать проблему с тормозами в реляционных базах при обработке security/иерархий. Для примера рассмотрим такую задачу: нужно вывести список всех "моих" задач в доступных мне подпроектах продукта X. В системе типа bugzilla это решается одним простым SQL запросом.

Но в TrackStudio есть иерархия задач, плюс можно указывать security для проектов, конкретных задач, категорий задач, кастом-полей. Посмотрим, к каким дополнительным действиям это приведет:

1) Сначала нужно понять, какие задачи вообще относятся к продукту X. Для этого нужно взять продукт X, получить список его подзадач, для каждой из них - опять список подзадач и т.п. Если у нас 2000 задач - нужно выполнить 2000 запросов только чтоб убедится что у этих задач нет подзадач. Тут можно сократить количество запросов за счет использования "in (список номеров задач)", но тогда мы не сможем построить дерево, которое нам пригодится потом. Оракловый START WITH/CONNECT BY будет полезен именно на этом этапе, т.к. позволяет собрать все дочерние элементы одним запросом. Есть варианты другой организацией дерева (например, parent task хранит диапазон ID дочерних элементов), но тут возникают проблемы с модификацией дерева задач.

2) Теперь нужно получить какие задачи видит данный пользователь и его список ролей (групп) для каждой задачи. В TrackStudio пользователь может быть менеджером в проекте A и одновременно быть разработчиком+тестировщиком для одной конкретной задачи в проекте B.
Причем права наследуются: если мы сказали что Вася будет менеджером в проекте A, нам не нужно это повторять для каждой задачи проекта, хотя для любой из них мы можем сказать - "а вот для этой задачи Вася будет еще и тестировщиком".

Т.е. теперь мы должны для каждой задачи получить цепочку ее parent task-ов, проверить какие для них заданы роли, как и где они были переопределены и в итоге мы получим список ролей пользователя для каждой из этих 2000 задач. Если мы не храним конфигурацию дерева в памяти - нам нужно получить цепочки parent task-ов 2000 раз и куда-то сохранить результаты его обработки.

Дело осложняется правилами для групп типа: "все разработчики имеют доступ к этому подпроекту" или "для этого проекта все разработчики отдела X являются тестировщиками", они влияют на список ролей для задач самым прямым образом.

3) Теперь нужно проверить правила видимости для категорий. Т.е. может быть указано, что "клиент видит только багрепорты, которые он внес сам и только в проекте customer support." Опять проверяем все задачи, достаем их категории, достаем список ролей для каждой задачи, проверяем может ли этот пользователь видеть эту конкретную задачу. Если не может - значит и все подчиненные задачи ему не доступны и их из списка выкидываем.

4) Какие задачи можно выводить - разобрались, теперь разбираемся с полями. Для каждой задачи на основе списка ролей получаем список всех полей, которые может видеть пользователь. Т.е. легко может оказаться, что в полученном списке задач пользователь может видеть бюджет у "своих" багов, а вот у проектов - не может вообще никак. Или что клиент не может видеть затрат времени разработчиков на задачу.

Главная сложность тут в том, что если права на задачу мы проверяли один раз для задачи, то тут нужно проверять для каждого _поля_ каждой задачи: они легко могут быть разными у полностью одинаковых задач, но находящихся в разных состояниях.
Даже если проверка выводить/не выводить данное поле делается 1 запросом и у нас в фильтре 10 полей - получаем 2000*10 = 20000 запросов.

5) Только теперь можно отфильтровать из этих 2000 задач "мои". "Скрывать" информацию нужно было именно до фильтрации, иначе умные клиенты смогут довольно быстро угадать значение скрытого поля выдавая набор запросов типа "вывести задачи где затраты на разработку больше 1 часа", "а теперь больше 2", etc. Если в первом запросе задача вывелась, а во втором исчезла - значит затраты времени на нее от 1 до 2 часов.
Дело тут осложняется пользовательскими полями (значения которых хранятся в отдельных таблицах со сложными связями) и вычисляемыми полями, для которых значение считается скриптом при обращении. Причем при выполнении скрипта действуют те же самые правила: если поле не видно - его не видно и из скрипта.
Макс Васенковwinzard on Декабрь, 14, 2007 04:37 (UTC)
Макс, ну фильтрацию по вычисляемым полям все равно на уровне СУБД не сделаешь, так что зря ты столько расписывал :)
(no subject) - sergsuper on Декабрь, 27, 2007 14:00 (UTC) (Развернуть)
(no subject) - maximkr on Декабрь, 27, 2007 14:05 (UTC) (Развернуть)
(no subject) - sergsuper on Декабрь, 27, 2007 14:11 (UTC) (Развернуть)
(no subject) - sergsuper on Январь, 17, 2008 15:02 (UTC) (Развернуть)
(no subject) - maximkr on Январь, 17, 2008 17:18 (UTC) (Развернуть)
(no subject) - sergsuper on Январь, 17, 2008 19:07 (UTC) (Развернуть)
(no subject) - maximkr on Январь, 24, 2008 22:59 (UTC) (Развернуть)
(no subject) - sergsuper on Январь, 25, 2008 07:38 (UTC) (Развернуть)
(no subject) - maximkr on Январь, 25, 2008 12:25 (UTC) (Развернуть)
(no subject) - sergsuper on Январь, 17, 2008 15:30 (UTC) (Развернуть)
(no subject) - maximkr on Январь, 17, 2008 17:57 (UTC) (Развернуть)
(no subject) - sergsuper on Январь, 17, 2008 19:24 (UTC) (Развернуть)
(no subject) - sassa_nf on Август, 10, 2010 20:03 (UTC) (Развернуть)
Максим Крамаренкоmaximkr on Декабрь, 13, 2007 23:03 (UTC)

6) Теперь проверяем данные. Например, если нужно вывести в качестве значения поля ссылку на задачу, а прав доступа к той задачи нет - выводим просто ее номер, иначе - полный путь. Т.е. для каждого _значения_ нам опять нужно повторять пункты 1-3, заранее собрать эту инфу невозможно.

В итоге получаем, что для не самого сложного случая вывода 1 страницы со списком багов нам придется получать список parent-ов/children-ов обрабатываемых задач десятки тысяч раз. В реальных условиях метод получения children-ов/parent-ов может вызываться сотни тысяч и даже миллионы раз для обработки одной страницы.

Решение - держать в памяти конфигурацию дерева, права и группы пользователей на все, значения полей от которых могут зависеть права (submitter/handler/state), и самим управлять этими данными. Но в этом случае состояние БД не полностью отражает состояние системы и все синхронизации кешей, обработки rollback-ов, выставления блокировок, борьбу с deadlock-ами нам надо делать для внутренних структур ручками.

Как только мы пошли по этому пути - про поддержку СУБД атомарности, уровней изоляции транзакций, работы в кластере и прочее можно забыть: если сами сделаем репликацию блокировок внутренних структур между узлами кластера - хорошо, не сделаем - будет глючить под нагрузкой.

Думаю, не мы одни на эти грабли встали. Microsoft когда-то анонсировала что в Windows Vista будет WinFS, революционная файловая система на основе РСУБД, а в итоге
http://en.wikipedia.org/wiki/WinFS
"While it was then assumed by observers that WinFS was done as a project, in November 2006 Steve Ballmer announced that WinFS was still in development, though it was not clear how the technology was to be delivered."

Подозреваю, что иерархия папок + что-то вроде NTFS security очень плохо ложится на реляционную модель.

Много ковырялся с внутренностями MS Exchange/Active Directory - они почему-то тоже вместо реляционной СУБД (того же SQL Server) используют ESE, который очень быстрый, но совсем не SQL.

На предпоследнем JUG-е elizarov (http://elizarov.livejournal.com) рассказывал на примере обработки биржевых сигналов, что для массовой обработки сообщений JMS вообще не пригоден (жутко тормозной и решает не те проблемы), а ему никто почему-то не верил :-)
Ruslan Kosolapovgrundik on Декабрь, 14, 2007 11:52 (UTC)
Ну, изначальный пост содержит довольно много неправды.

start with/connect by есть в postgresql, например, аналоги есть и для других РСУБД.
security по полю есть вообще много где.

Другой пост, более подробный, выглядит так, будто матчасть изучена неполно (не знаю, может это просто так выглядит, но писать про деревья и не упомянуть Селко, при этом упомянуть два других аглоритма - ну как это можно понять?) Плюс наверняка многое решается другой структурой данных (возможно, денормализованной). Вообще, я не понимаю, зачем BL складывать на РСУБД, когда проще сделать ORM (с lazy заполнением пропертей и с memoize), и всю BL делать на стороне приложения, тогда и кучи запросов не будет (по памяти просядем, конечно). Ну и если вы делаете BL на стороне РСУБД, то видимо логичнее использовать stored procedures, а не гонять туда-сюда запросы и результаты запросов. И не стоит недооценивать алгоритмы кеширования РСУБД, там чуваки очень мощные сидят, довольно сложно их переплюнуть.

Конечно, вам виднее, но ваши слова не выглядят убедительными, по крайней мере для меня.

А по сути наверное соглашусь.
Максим Крамаренкоmaximkr on Декабрь, 14, 2007 14:18 (UTC)
> start with/connect by есть в postgresql, например, аналоги есть и для других РСУБД.

Ну, выбирать как с этим работать нам приходилось в где-то в 2001 году, тогда start with / connect by в postgresql был доступен только в виде патча. Мы с этим тогда поигрались, но учитывая опыт с ORACLE связываться с этим не хотелось, плюс не понятно что с другими базами СУБД делать.

> security по полю есть вообще много где.

Хочется примеров. Пока то что я видел - это не та security, т.е. формально что-то делается, но не то. Т.е. я не знаю как сделать на уровне SQL, чтоб попытки от имени работников запросить зарплату директора возвращали NULL, и при это нормально работали для других полей и записей. Или чтоб при вычислении AVG(SALARY) зарплата директора исключалась из рассмотрения. Причем это решение должно обеспечивать нормальное управлениями тысячами правил доступа без особенного мудрежа со стороны пользователя.

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

BL мы на РСУБД не складываем, бесперспективность этого стала понятна быстро. ORM с lazy-заполнением и хранением в памяти результатов запросов (query-level cache) в лице Hibernate используем где нужно уже несколько лет. Попытки отказаться от наших структур и использовать только кеши ORM (это позволило бы сильно упростить код) приводили к падению скорости на порядок и более.

В общем я не думаю, что мы сделали где-то большую глупость и задача легко решается средствами РСУБД. Я ведь этой тематикой давно интересуюсь: когда был студентом (эх, молодость:) - довольно серьезно интересовался реляционной теорией, внутренним устройством РСУБД, читал умные книжки (Мейер и пр.), переводы буржуйских статей в "открытых системах", трепался с Лилией Козленко из Линтера в фидонете и даже собирался туда устраиваться на работу :-) Потом была возможность посмотреть как оно все на самом деле сделано - долго работал (да и сейчас работаю) в проекте, включающем большой кусок ковыряний внутренностей SQL Server/SyBase/ORACLE/PostgreSQL/MySQL/Exchange. Потом TrackStudio.

Думаю, что все-таки есть задачи, с которыми РСУБД справляются крайне криво и наш случай - это оно.
(Анонимно) on Декабрь, 27, 2007 14:21 (UTC)
Ужос, наймите архитектора, прежде чем кодить !
1. ваша задача просто создана для оракла с его connect by
2. ВСЕ современные субд имеют иерахические запросы mssql, db2 это WITH, postgres есть патч с connect by
3. если вдруг у вас отсалый mysql есть патерн Celko Tree, ВСЕ ваши запросы при этом патерне сводится к ОДНОМУ селекту по нескольким индексам.
4. Я тестировал, connect by из oracle 10.2 как примерно равен по скорости Celko Tree - значит варианта 2: у вас руки кривые или 15 лет назад 8i был еще не на высоте. короче планы в студию.
5. закрытие полей для тех пара ролей, что есть багтрекерах элементарно делаются через вьюшки. row level security в оракле уже 7 лет, но только в EE редакции, вам за глаза хватит вьющек на каждую роль. если вьюшками не обойтись, простенькая логика на список полей и динамический SQL (если уж так лень расписывать все варианты в if'ах).
Максим Крамаренкоmaximkr on Декабрь, 27, 2007 14:34 (UTC)
Re: Ужос, наймите архитектора, прежде чем кодить !
Всю переписку читали ?

Celko Tree не катит, там модификация дерева довольно тормозная получается, получаем те же проблемы, но в профиль. Вьюшки тоже совсем не вариант по многим причинам.

А база у нас любая - ORACLE, MySQL, MS SQL, PostgreSQL, HSQLDB, Firebird, DB2.
Борменталь (мл): South parkdr_bormental on Декабрь, 28, 2007 13:26 (UTC)
Хотя на первый взгляд пульты кажутся очень похожими, это серьезное внутреннее ограничение магнитофонов, а не досадная недоработка разработчиков пульта.
Не в силах понять, что же было написано во всех предыдущих абзацах, могу прокомментировать этот тезис.
Во-первых, кнопки перемотки по трекам есть на любом более-менее нормальном стационарном приборе, а также почти во всех кассетных плеерах. Поиск трека осуществляется по паузе (что очень логично, не правда ли?). Во-вторых, есть профессиональная аппаратура, где поиск на плёнке ведётся по индексу, который записывается параллельно данным. Так что отсутствие кнопок нельзя сводить к ограничению магнитофонов (как устройств воспроизведения). Скорее, это издержки технологии, основы которой закладывались тогда, когда с электроникой было туго.
Максим Крамаренкоmaximkr on Декабрь, 28, 2007 13:44 (UTC)
Понял, спасибо. У нас тут проблема очень близкая - хотя поиск в магнитофонах как бы есть, но он сделан не в лучшем виде и использовать его сложно. Если им приходится пользоваться раз-два в день - нормально, а если мы захотим на его основе сделать "интерактивную кассету" (например, обучалку ПДД), где такие поиски происходят раз в несколько секунд - получится очень медленно. А что если сделать файловую систему на кассете ? :-)

Аналогично и с security/иерархиями в реляционных СУБД - они как бы есть и поддерживаются, но коряво и в самых дорогих версиях отдельных продуктов, делать это основой своего продукта не хочется.
(Анонимно) on Январь, 6, 2008 07:38 (UTC)
> Проблема тут в том, что реляционные СУБД вообще плохо подходят для написания приложений типа TrackStudio по принципиальным соображениям:

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

> Из всех популярных РСУБД только в ORACLE есть start with/connect by,

Я люблю и ценю Oracle, но утверждение запоздало лет на пять...

> Маленький пример из другой области: у кассетных магнитофонов и DVD-плееров пульты почти одинаковые, но на пульте магнитофона нет кнопок перехода к следующей/предыдущей записи. Хотя на первый взгляд пульты кажутся очень похожими, это серьезное внутреннее ограничение магнитофонов,

Маленький пример: берите хорошие магнитофоны. На моей Вега-122МП такое кнопки есть. Удачно иллюстрирует логику сказанного :)
Максим Крамаренкоmaximkr on Январь, 6, 2008 12:37 (UTC)
> Мягко говоря, спорно - слишком много таких систем написано и успешно работает. В целом все сказанное
> здорово напоминает очередной гимн объектной либо сетевой СУБД, вся прелесть которых в том, что автор их
> еще не пробовал (не собираюсь утверждать - пробовал или нет; говорю лишь - напоминает).

А можно примеры ? То что я видел - там системы не совсем такие, т.е. или количество уровней в иерархии ограничено, или количество элементов, или значительную часть опций security можно задавать только для проектов и прочих контейнеров.

Гимн объектной или сетевой СУБД не пою :-) Одно время игрался с Cache' и db4o, совсем не впечатлило, но от этого наши проблемы с реляционными СУБД меньше не стали.

> Я люблю и ценю Oracle, но утверждение запоздало лет на пять...

Да, именно тогда мы и выбирали вариант реализации :-). Еще был патч для PostgreSQL, но производительность была "не очень", так что ковырять в этом направлении дальше смысла не было.

> Маленький пример: берите хорошие магнитофоны. На моей Вега-122МП такое кнопки есть.
> Удачно иллюстрирует логику сказанного :)

Иллюстрирует даже более удачно, чем кажется на первый взгляд :-) Попробуйте на том магнитофоне использовать перемотку для реализации "интерактивной кассеты" (типа обучалки ПДД), т.е. пользователь жмет кнопки, а ему в соответствии с нажатиями проигрываются разные куски. Или файловую систему сделать :-)

Тут ситуация ровно та же - формально реляционные СУБД с иерархиями работать умеют, если их не сильно этим грузить - справятся, но это не является их сильной стороной.


(Анонимно) on Февраль, 7, 2008 19:57 (UTC)
по отношению к самой задаче
Если сужения прав ниже той точки, где они были выданы, не бывает. То можно эксплуатировать очень простой факт: права доступа на системе в эксплуатации будут выдаваться руками, поэтому количество точек выдачи доступа будет меньше, чем любых других объектов.

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

От выбранных точек древовидно вниз дальше можно делать все, не заботясь больше о security.
(Анонимно) on Февраль, 7, 2008 20:10 (UTC)
Re: по отношению к самой задаче
Кроме того, field-level security на уровне базы данных не нужна, можно сперва выбирать из базы небольшой subset объектов, разрешенных для отображения вообще, и уже при отображении разбираться с правами доступа к отдельным полям.

В худшем случае в выборку попадет объект, у которого все поля недоступны, и поэтому он не должен был попадать в выборку. Если такая ситуация, -- пользователю по row-level security разрешен доступ к объекту, а поля его запрещены все, -- не частая, то это можно как-нибудь замаскировать, никто не пожалуется.
Максим Крамаренкоmaximkr on Сентябрь, 25, 2008 08:56 (UTC)
Про Exchange 2007
Читаю тут Windows IT Pro за октябрь 2007, там есть статья про Exchange 2007. Ну и начало там такое:

No SQL Server ?
The biggest change that many expected to occur in Exchange 2007 was a transition to Microsoft SQL Server as the database engine for the Store. However, when the Exchange developers investigated the challenges of forcing a database engine designed for structured transactions to handle the work generated by Exchange and its clients, they decided they couldn't do it for Exchange 2007.

Ну т.е. ровно та же история: большинство пользователей считают - можно и нужно, разработчики считают - нельзя, и объясняют это именно особенностями генерируемой нагрузки и неприспособленностью реляционных СУБД к такой нагрузке.
(Анонимно) on Октябрь, 31, 2008 17:17 (UTC)
Re: Про Exchange 2007
странные у вас ассоциации. имхо скорее покапавшись они обнаружили что система спроэктирована так, что дешевле забить чем пытаться "это" натянуть на реляционную структуру. например они не придумали способов как mssql бы не просела от долбежа запросов в цикле.

Triffids.
Филипп Дельгядоdph on Август, 14, 2010 21:31 (UTC)
Хм, когда мне надо было много и эффективно работать с деревьями в БД, я просто оптимизировал хранение и разменивал скорость чтения на скорости вставки/изменения.
Например, сортировка дерева и хранение для каждой ветви кода "брата" - очень упрощает и ускоряет запросы. Особенно если по этому полю еще и физически сортировать. При вставках и модификациях, конечно, требуются довольно большие update - но это не так часто и все равно одним-двумя операторами.
На нормальных БД (мне пришлось делать на MS SQL, но гораздо лучше такое делать на DB2) все работает очень даже шустро. С учетом потребностей трекера - хоть на бесплатной версии и поставлять с продуктом )

Ну а права, конечно, нужно каким-то образом предвычислять (стратегий там много, зависит от конкретных требований). Но ничего неимоверно сложного там тоже есть, да и объемы у вас достаточно маленькие, да и нагрузка тоже весьма ограничена.
Максим Крамаренкоmaximkr on Август, 14, 2010 21:59 (UTC)
Мы в итоге пошли не по пути предвычисления, а по пути кеширования всего в памяти. Лучше это или хуже - затрудняюсь сказать.

Из соображений скорости нам в принципе хватило бы in-memory движка, поддерживающего persistence на диск. Т.е. который требовал бы, чтобы база целиком помещалась в память, но который при этом мог бы выполнять десятки тысяч поисков по ключу в секунду. Фактически, 60% кода TrackStudio - это и есть реализация подобного движка, но т.к. изначально ничего такого не задумывалось - движок получился довольно корявым.

(no subject) - dph on Август, 14, 2010 22:12 (UTC) (Развернуть)
(no subject) - maximkr on Август, 15, 2010 07:31 (UTC) (Развернуть)