Максим Крамаренко (maximkr) wrote,
Максим Крамаренко
maximkr

Реляционные СУБД и TrackStudio

kranov пишет, что наш способ хранения длинных строк в СУБД (с разбиением строк на кусочки и сборкой через SQL при необходимости) есть кривизна и об этом стоит помалкивать, а не рассказывать как о преимуществе TrackStudio при сравнении с JIRA:

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

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

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

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

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

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 65 comments