Хранение древовидных структур в mysql(+)

А версия какая? А настройки InndoDB? Макс. размер логов?

В 3.23.x большие таблицы InnoDB очень медленные. Попробуйте сделать какой-нибудь агрегат на таблице, скажем в 1 млн. записей.

В 4.x не знаю, еще не успел плотно опробовать.

Вообще mysql подходит для несложных вещей. А если необходимы надежные транзакции или, скажем, хотите непременно реализовать бизнес-логику на стороне СУБД, тогда mysql не подойдет однозначно. Тоже самое и со сложными структурами(например, которые сами себя поддерживают). Тот же nested sets при помощи хранимок и триггеров — сказка, а в mysql приходится всю логику на клиентской стороне реализовывать.

Мне в принципе нужно от СУБД в данном случае просто хранить данные(индекс) ввиде дерева.

p.s. Кто-нибудь знает, где можно получить sql for smarties(а лучше sql hierarchy structures) в электронном виде, там вроде Celko описывает различные деревья в sql-реализации.

А вообще реляционные СУБД в принципе не подходят для иерархических данных(ну может кроме нового SQL Server 2005, там вроде встроили поддержку средставми расширения стандарта ANSY SQL).

Смотрю в сторону Posgres. Там по-моему есть все, что нужно, и бесплатно:)

p.p.s. Почему же все-таки хочется SQL? Ответ прост: проще работать с данными, чем на c++(тут же по сути придеться писать свою мини субд, а хранилище будет файловая система).

А как вспомню, что нужно опять работать вручную с памятью, аж в дрожь бросает:))

Скажу возможно крамольную вещь, но все же:

Если у вас нет необходимости работать руками с памятью и указателями — не работайте, ибо машина скорее всего сделает это не хуже вас. За примерами ходить далеко не надо. CLR, JRE и т.д. Но уметь это и понимать как все это работало в прошлом веке вы обязаны:)

Sherman, Там, где нужно работать с памятью и указателями, не всем средам можно доверять (это не сама машина :), а всего лишь компиляторы и интерпретаторы). Утечки памяти и переполнения есть почти везде.

Версия MySQL - 4.1.11.

И мне кажется, что при сборке ее с либами gcc-3.4.2 порой возникают какие-то внутренние конфликты. Потому как этот компилятор более жесткий - он практически не признает warning'ов...

Настройки InnoDB варьировала по-разному. Насколько могу видеть, размеры логов в конфиге не превышают допустимого... буду еще разбираться. Проблем выше крыши и без этого...

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

Кстати, в треде про подбор СУБД мы поднимали тему, что для специфичной задачи, критичной по времени, требуется все-таки своя мини-СУБД.

Насчет с++, я имел ввиду под «машиной» именно среду, незря же привел примеры. Мне кажется человек может допустить ошибку даже чаще, чем автомат, т.к. эти области(манипуляции с указателями, например) весьма нетривиальны. В C# это и еще кое-что вообще убрали, и не только из-за несовместимости с CLR, а как раз потому что CLR гарантирует безопасную работу с памятью, а работа с указателями в ручную этого не гарантирует, хотя можно это использовать в блоках unsafe code.

mysql 5 еще долго будет оставаться alpha, beta, pre, rc, etc. Когда она будет stable известно наверное только одному Богу:)

У меня задача не настолько критичная, чтобы отказываться от SQL, как от языка работы с данными, реализовывать же его самостоятельно — не просто.

Sherman,

Да, чтоб отказаться от стандартной СУБД, надо иметь веские причины.

С другой стороны, иногда необязательно самостоятельно реализовывать весь SQL - достаточно знать, что именно необходимо.

Если уж речь зашла о c++, советую всё-же отказаться от mysql, и разработать свою БД. Алгоритмы все известные, а на писанину времени уйдёт не более чем, на поиски приручения mysql. Естественно плюсы - своё = что хочу то и ворочу + оптимизация под конкретную задачу.

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

Я уже высказывал свое мнение , mysql для задач индексации не годиться вообще . Mysql - заточен в два конца , на чтение и на вставку . При таком подходе в любом случае будут излишние накладные расходы на хранение данных , на их обработку . Разумно использовать mysql под коллекционирование данных. А выдачу для клиента оптимизировать с учетом одноразовой записи и многоразовой выдачи. Mysql удачен для длинних записей , не для организации деревьев.

alyak, А кэширование? Возможно, оно подойдет и при mysql, если разумно настроить кэш....

lagif, а файловая система куда как лучше кешировать будет.

Деревья в SQL. Часть 1.

Ты тему читал? Это и есть прототип nested sets. Но он тут не подойдет, т.к. слишком часто и по-многу будут проходить insert-ы. А в nested sets нужно каждый раз перестраивать дерево почти полностью, для вставки одной записи.

Nested Sets оптимально использовать для каталога. Выборка идет почти всегда одним запросом. И там где захлебнется parent-child, nested sets прекрасно будет себя чувствовать, единственные проблемы с сортировкой здесь. Но и их можно решить разными способами.