PEAR:DB_NestedSet кто-нибуть юзает?

[crocodile2u]

Да это понятно
Но все же - если мускуль не поддерживает сиквенсы, зачем его заставлять это делать насильно?

 

[kvf77]

he][es

вот именно, что это твое ИМХО, если бы ты взял на себя труд делать что-нить сложнее простых манипуляций с базой, тогда бы узнал зачем нужны сиквенсы. И не пытался бы определить ИД которая сгенерировала база командой, которая незнамо какой правильности результат тебе возвращает. Тебе ниразу не приходила мысль, что если бы это было правильнее, то так бы везде и было, а не тока в Мускуле?

Как раз ошибаешься - автоинкремент - это сиквенсы через жопу А что ты будешь делать со своим автоинкрементом, когда тебе нужно будет генерировать спрошные ИД сразу для разных таблиц?

crocodile2u
никто насильно его это делать не заставляет. дело в том, что сиквенсы нужны и для других дел - а единообразие работы с уникальными значениями позволяет быстро и эффективно с ними работать. попробуй, например, получить ИД раньше, чем ты произведешь запись в таблицу. Не получится у тебя это с автоинкрементом. Тогда как периодами требуется на основании ИД сделать определенные записи в другие таблицы, или в файл, а потом произвести вставку той записи, которая при автоинкременте тебе даст нужный ИД.

В общем - спорить тут конечно можно - но я не считаю что "заставляю" Мускуль искуственно следовать правилам. То что данная конкретная задача не требует категорически сиквенсов ни о чем не говорит

 

[crocodile2u]

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

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

В общем, рискуя показаться непоследовательным, скажу: использование сиквенсов в данном случае оправдано А вообще, следовало бы, наверное, перенести часть дискусси про сиквенсы в свой топик, ведь к DB_NestedSet она имеет лишь опосредованное отношение, имхо...

 

[he][es]

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

Ну если сомневаться в правильности команд БД, то с ней вообще не стоит работать... (разве не так?)

А что ты будешь делать со своим автоинкрементом, когда тебе нужно будет генерировать спрошные ИД сразу для разных таблиц?

Не совсем понимаю...
Возможно мое ИМХО - плод моей безграмотности и непонимания проблемы, тогда объясните пожалуйста мне их глубинный смысл!..
Я например не хочу заморачиваться с id записи. Ведь это так просто свалить на плечи БД.
Если мне нужен ID записи,то мне в принципе без разницы, когда я его получу, до или после вставки записи в таблицу (путем того же LAST_INSERT_ID()). Если я его хочу где то использовать, то скорее всего это связанные запросы, и при невыполнении одного, я путем транзакций откачу все. Зачем тут сиквенсы?

А вообще, следовало бы, наверное, перенести часть дискусси про сиквенсы в свой топик, ведь к DB_NestedSet она имеет лишь опосредованное отношение, имхо...

Угу...

 

[kvf77]

he][es
простите, откуда в MySql транзакции?

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

 

[Sad Spirit]

Автор оригинала: he][es
Не совсем понимаю...

Пример (для PostgreSQL):

create sequence ab_seq;

create table a (
    a_id integer default nextval('ab_seq') not null,
    ...
);

create table b (
    b_id integer default nextval('ab_seq') not null,
    ...
);

В результате имеем 2 таблицы, в которых id уникальны. Это может быть нужно при создании всяких хитрых зависимостей и т.п.

А теперь покажи, как это реализовать в мыскле с использованием autoincrement...

Если мне нужен ID записи,то мне в принципе без разницы, когда я его получу, до или после вставки записи в таблицу (путем того же LAST_INSERT_ID()). Если я его хочу где то использовать, то скорее всего это связанные запросы, и при невыполнении одного, я путем транзакций откачу все. Зачем тут сиквенсы?

Если база поддерживает sequence'ы, то значение ты тоже можешь получить и до, и после, и вообще не заморачиваться.

Вот если их эмулируют для более убогих СУБД, то да, придётся использовать nextId(), но зато потом получится перенести приложение с более убогой СУБД на менее убогую, не заморачиваясь с переделкой mysql_insert_id()...

 

[he][es]

kvf77

простите, откуда в MySql транзакции?

Вот это уровень показывает... Когда я в чём то не уверен, прежде всего я перепроверю себя. А вы думаете что вы всё знаете?.. Что бы не выглядеть голословным достаточно смотреть локументацию...
http://dev.mysql.com/doc/mysql/ru/transactional-commands.html
Для саморазвития, теперь там есть и хранимые процедуры, транзакции, и много чего ещё. И пусть пока (надеюсь уже не долго) это бэта...
Sad Spirit м.... ну да, есть фишка.

ну а конкретнее объяснять смысла нет

Он всегда есть. Человек должен рости. И

когда сталкнешься с подобной задачей

будешь выкручиваться как сможешь, незная простых вещей... Sad Spirit спасибо за объяснение. я бы наверное реализовал это на уровне кода (РНР)... Хотя так конечно элегантнее...

 

[kvf77]

he][es

ну если ты гоняешься за бетами - то я нет - так что пока это все не устоится в мускуле - я не вижу в упор этих возможностей - так что профессионализм тут не причем. К томуже это все работает тока для таблиц InnoDB (а об этом я давно знал, думал, что и для MySam уже сделали, ан нет), и мне это не интересно.

Чток асается роста - то не вижу смысла себя загружать подобного рода зананиями, если они тебе не нужны. К тому же ты совершенно не внимателен, и то, что тебе сказа Sad Spirit я сказал намного раньше - достаточно прочитать мой пост объемный тебе и ты увидишь теже самые слова, так что мне тоже мог бы спасибо сказать

 

[algo]

Что касается секвенсов - они делаются в Мускуле, начиная с 5.0.10

Несколько через задницу, но полностью корректно.

Sad Spirit

Сплошные id для нескольких таблиц через секвенс - это полезный трюк, но он грязный, вообще говоря.

ID должен быть Primary key, уникальным.
Ты можешь сделать constraint для уникальности ключа в одной таблице, но у тебя не получится сделать unique constraint для двух таблиц, чтобы гарантировать уникальность ID в их объединении.


All
Очень хорошая вещь есть - называется helper table.

А еще есть contrib/ltree , который начиная с 8.1 уже не такой кривой как раньше (хотя и не прямой окончательно).

Выкиньте этот Nested Sets нафиг.. Апдейты - смерть от них, а?

 

[kvf77]

algo

половины не понял из твоего сообщения если честно - ты щас с кем разговаривал? особенно в обращении к Sad Spirit?

и, на будущее, не надо указывать на фичи нестабильной версии баз данных - вот когда будет нормальный релиз 5 версии, тогда мы обратим на нее внимание.

последний пункт - вообще твое субъективное мнение - надо быть осторожнее в формулировках

 

[he][es]

Я вот тут что подумал. А нафига подобная конструкция может быть нужна?..

create sequence ab_seq;

create table a (
    a_id integer default nextval('ab_seq') not null,
    ...
);

create table b (
    b_id integer default nextval('ab_seq') not null,
    ...
);

Ведь ID - идентификационный номер записи, так?.. по нему ссылаются на запись, а если мы не знаем в какой таблице эта запись хранится как мы можем на неё ссылаться?.. (или я чего то опять не догоняю?)

так что мне тоже мог бы спасибо сказать

Да спасибо то оно само собой!..
algo а можно попобробнее?.. Со ссылками...

 

[kvf77]

he][es

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

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

 

[he][es]

Хм... Что то я в смятении и смущении. С одной стороны вроде и да, но я не вижу однозначной полезности и 100% необходимости сиквенсов. В приведенном вами примере я бы сделал одну таблицу и у непровереных/неисправленых (видимо вы это имели ввиду) записей поставил бы флаг...
И не увидел ответа на мой вопрос: как ссылаться на запись не зная в какой таблице она находится?!.. К примеру есть последовательность:
id - имя
1 Вася (тбл.1)
2 Петя (тбл.2)
3 Сережа (тбл.2)
4 Женя (тбл.1)
5 Саша (тбл.2)
Нам надо получить инфу о номере 3. Где искать? Как написать запрос?..
(пока не убеждён... )

 

[crocodile2u]

То, что говорит algo - имхо, вполне понятно, и я лично практически со всем согласен. Кроме, пожалуй, последнего утверждения - по-моему, всякому овощу свое время и место - и NestedSets иногда бывают весьма полезны (хоть я и стараюсь использовать Adjacency Lists везде, где не бывает критичной скорость выборки)...

-~{}~ 28.09.05 10:39:

he][es
Ну, Sad Spirit привел лишь, так сказать, теоретический сугубо пример. Вот пример, на мой взгляд, более жизненный:

имеем две _различные_ сущности, данные которых хранятся в двух разных таблицах, в каждой есть свой PrimaryKey.
Кроме этого, имеем третью сущность, которая связана один к одному и с первой, и со второй (допустим, храним там... ну, скажем, данные о последнем обновлении той или иной записи - не совсем реальный все же пример, ну да пусть будет так). Если наше приложение подразумевает уникальность ID в пространстве _двух_ таблиц - мы не имеем никаких проблем. А вот если нет... А то, о чем говорил algo - это тот момент, что сама база не обеспечит требуемую уникальность - то есть, допустим, новый, зеленый, админ залезет в базу, минуя наше приложение, и испортит всю малину...

 

[kvf77]

he][es

обычно ты всегда ищешь (воспользуемся приведенным примером) аппрувленного юзера, если ты его не нашел - ищешь в неаппрувленых. в общем-то, как я говорил раньше, раз тебе оно не надо - не заморачивайся.

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

к NestedSets же я попросту превых, да и средств (в том числе и моя либа) написано много, считаю их удобными и эффективными

 

[crocodile2u]

kvf77
Сиквенсы, безусловно, рулят! Я и не собирался с этим спорить. Я лишь возражаю против неосмысленного использования (имитации) сиквенсов в БД, которая не имеет их поддержки. Мне приходилось сталкиваться с тем, что программист, используя PEAR:B, пихает сиквенсы при любых вставках, несмотря на то, что его приложение, на 100%, не будет никогда использоваться с БД, отличной от MySQL.

 

[kvf77]

crocodile2u

еще бы какой провидец заверял меня каждый раз на 100% по поводу того или иного моего приложения

 

[he][es]

ну ладно... Допустим убедили с одной стороны смысл вижу, с др. видимо пока не столкнусь с ситуацией где без них никуда не прочувствую...
crocodile2u По поводу зеленого админа... так так везде. файлик потрет. таблицу грохнет... Я вот тут на одном форуме с такой инициативой/предложением выступил по поводу NestedSets: написать процедуры для БД (хранимые) занимающиеся обработкой NestedSets. Добавлением, удалением, и т.п., перенести PEAR:: DB_NestedSets в БД вообщем... На что конструктивной критики не получил. Скажите вы мне это: глупо и не нужно, умно но не нужно, нужно но нафиг никто делать не будет, или это не рально и как говорится того не стоит?... (основные БД MS, Prog, My(скоро, не пинайте, что бэта, я в неё верю! ) ...продолжите список. поддерживают Хран.Проц. ясно что "диалекты" могут отличаться...)

 

[kvf77]

he][es
ну я бы сказал, что это чуть ли не единственно правильный вариант - если база поддерживает хранимые процедуры, надо писать по возможности обработку деревьев в хранимках

 

[algo]

he][es что именно интересует подробнее ?

Про секвенсы в mysql - например, вот тут
http://www.livejournal.com/users/arjen_lentz/34627.html
Текущую бету вполне можно использовать для разработки.

Ведь ID - идентификационный номер записи, так?.. по нему ссылаются на запись, а если мы не знаем в какой таблице эта запись хранится как мы можем на неё ссылаться?..

Действительно, ты прав. Это реальная проблема... Не знаю, как ее достаточно удобно решить в postgres/mysql.

Я использую общие ID для
1) составления единых иерархий из нескольких типов объектов. Для выборок из таких иерархий использую Postgresql Inheritance, а поддержание целостности - используя(обычно) отдельные pid-поля для каждого типа родителей.
2) для пермишнов. Скажем, т.к User Id и Group Id находятся в едином адресном пространстве id, то "User 1 такой-то имеет разрешение на объект 2" и "Группа 2 имеет разрешение.." записываются одинаково - через пару ID.
3) для кэширования. Кэшить объекты можно по ID вместо связки "ID-тип".

Nested Sets выкиньте нафиг, зачем оно вам?
Он требует
1) чтоб иерархия была почти статической
2) информация о числе потомков правдива только в случае отсутствия разрешений

Пункты 1 и 2 могут не играть роли в конкретном приложении, но серьезно ограничивают применение подхода.
С другой стороны, "helper table" определяется как вспомогательная таблица, которая для каждого pid хранит все id и level, на котором он находится(для удобства).
1) Прекрасно справляется со вставкой.
2) Хранит не какие-то левые right, left а реальные id, pid. Это удобно для выборок.

Собственно, фсе. Удобный универсальный подход.

Несколько менее универсально - использование ltree из postgresql/contrib.
Кто-нить его юзает уже, интересно?
Мне лично очень нравится пока..


crocodile2u
Да, я имел в виду именно то, что целостность данных гарантируется БД. Приятно знать, что нечто не может сломаться в принципе