PHP 4.4

> На этом, думаю, беседу можно закончить.

Да, уж, тебе пора баиньки, а утром в школу.

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

>А говорил, что с математикой дружишь. Бегом в третий класс пропорции изучать.

Смайлик видел?

>Взятых кем?

Отдельно взятых. Это оборот такой есть в русском языке. Синоним - выделенных.

>Ну, а тебя-то как это волнует/задевает? Ты же грамотный программер, и если бы пришлось писать на php, наверное, додумался бы использовать хотя бы PEAR::DB для работы с базой? Если да, то чего зря на язык наезжать? Я не понимаю ход твоей мысли.

Дак это я так, теоретизирую...

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

Ну привел ты пример с nested sets. Я так и не понял, в какую он тему. Почему запользованные фичи Oracle-а требует какого-то особого и специального интерфейса для использования, я тоже как-то не осознал - а ведь явно спрашивал. Потом ты меня оболгал - я тебе явно свои цитаты привел.

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

>Да, уж, тебе пора баиньки, а утром в школу.

На работу завтра, на работу... Оценивать проект на PHP...

Кинь ссылку на проект.

> Оценивать проект на PHP...

Хм, меня вот вопрос мучает, а как ты его собрался оценивать, не зная php? ;)

Хороший тред получился. Читать интересно :))) Спасибо :D

А у меня вопрос!

Есть много написанных(в т.ч. коммерческих проектов) на PHP, в которых используются mysql_connect(mysql_pconnect). Как можно их перенести на "идеологически правильный" PEAR::DB? Переписывать код - не предлагать.

> А при том, что если правильно использовать сей магический интерфейс, то руками эскейпинг делать не надо. Пример:
> PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES SET DESCRIPTION = ? WHERE ID = ?");
> pstmt.setString(1, userEnteredDescription);

Ключевая фраза: "если правильно использовать", ключевое слово: "если" ;)
Расскажи нам, что может получиться, если пионер, пишущий этот код
использовал данный магический интерфейс неправильно. Например, он вместо
setInt() прописал setString(). Ошибки он не заметит, база тоже строчку
схавает без вопросов, а хакер элементарно подсунет в этот код
sql-injection.

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

Ну, такие проекты явно просятся в мусор. Я боюсь, что в них
mysql_connect - это самая последняя проблема, на которую стоит обратить
внимание ;) Классы-обёртки для работы с БД были доступны с незапамятных
времён. mysql_connect можно и должно вызывать один раз из одного
метода/функции.

Господ! Предлагаю для начала развести понятия программирования и кодинга.

опять на интелектуалов раб. класс наезжает.

>Хм, меня вот вопрос мучает, а как ты его собрался оценивать, не зная php? ;)

Кто сказал, что я его не знаю? По-моему, это только гнусные догадки. Я не гуру PHP, это точно, но что-то знаю.

>опять на интелектуалов раб. класс наезжает.

Наоборот. Интеллектуал на раб. класс наезжает.

Ключевая фраза: "если правильно использовать", ключевое слово: "если" ;) Расскажи нам, что может получиться, если пионер, пишущий этот код использовал данный магический интерфейс неправильно. Например, он вместо setInt() прописал setString(). Ошибки он не заметит, база тоже строчку схавает без вопросов, а хакер элементарно подсунет в этот код sql-injection.

Дык это Java, она не даст тебе вызвать setString() от int-а.

>Кстати, магический интерфейс вовсе не магический. Какого фига он заставляет программера руками назначать тип данных, когда гораздо надёжнее и очевиднее автоматически брать его из метаданных БД. Ведь типы полей уже определены в таблице. Вывод - данный интерфейс не страхует от человеческой ошибки, как ты утверждал.

Да, ты прав. Скажем так, не настолько страхует.

>Кинь ссылку на проект.

Э-м-м-м. А как же NDA?

>Да, ты прав. Скажем так, не настолько страхует.

Хотя чем опасна ошибка я пока еще не понял :)

> Еще раз. Я по крайней мере какие-то аргументы выдвигал. А ты так просто общими словами и наездами отбрехивался, в тех местах, где я тебя носом тыкал. Так ведь и не ответил по сути.
Я тебе ответил по сути. То что ты принял за общие слова есть общепринятая терминология в подобного рода обсуждениях. Если ты чего-то не понимаешь, это еще не значит, что то что тебе говорят вещь неправильная, неправда ли?

> Ну привел ты пример с nested sets. Я так и не понял, в какую он тему. Почему запользованные фичи Oracle-а требует какого-то особого и специального интерфейса для использования, я тоже как-то не осознал - а ведь явно спрашивал.
А ведь я тебе явно объяснял что реляционные модели могут зависеть от конкретной б.д. И дело не в оракле. Следи за темой.

> Потом ты меня оболгал - я тебе явно свои цитаты привел.
Потом я понял, что ты нифига не рубишь не только в сабже, но и вообще в предмете. Я тебе пару раз намекнул на это, потом пару раз сказал прямо. Потом обозвал быдлакодером. Нуль эффекта.
Те пофиг? Ну и мне тада пофиг. Я понял что с тобой разговаривать (надеюсь пока) неочем и предпочел закончить.
Тебе бы было приятней если бы я вместо "там" обозвал бы тебя домбоебом и послал на?
Да ради бога!
Я как тупой пхп-кодер официально заявляю, что хоть ты и якобы пишешь на жабе, ты тупой, мирный даун. Ты нихрена не понимаешь ни в теме топика в который влез, ни в предмете вообще. Вали читать мурзилку придурище.

>А ведь я тебе явно объяснял что реляционные модели могут зависеть от конкретной б.д. И дело не в оракле. Следи за темой.

Ну да, а значит пример с nested sets-ами был не в кассу? Пример-то про фичи БД был, а не про интерфейс с СУБД?

>Потом я понял, что ты нифига не рубишь не только в сабже, но и вообще в предмете. Я тебе пару раз намекнул на это, потом пару раз сказал прямо. Потом обозвал быдлакодером. Нуль эффекта.

Замечательная аргументация...

>Я как тупой пхп-кодер официально заявляю, что хоть ты и якобы пишешь на жабе, ты тупой, мирный даун. Ты нихрена не понимаешь ни в теме топика в который влез, ни в предмете вообще. Вали читать мурзилку придурище.

Слив засчитан.

>А ведь я тебе явно объяснял что реляционные модели могут зависеть от конкретной б.д. И дело не в оракле. Следи за темой.

Да, и дополнение. В основе-то все равно реляционная алгебра лежит. Опять же я не говорил, что интерфейс покроет все возможные фичи, я говорил, что основную часть. Например, ResultSet executeQuery(query) покрывает уже довольно значительную часть.

>Тебе бы было приятней если бы я вместо "там" обозвал бы тебя домбоебом и послал на?

Ай-яй-яй, как нехорошо. Это называется демагогия. "там" якобы я говорил, об абсолютно универсальном интерфейсе для доступа к СУБД, по твоим словам. Я такого не говорил. Когда я попросил ткнуть меня носом в мою цитату (эффект это имело бы больший, чем все твои ругательства), ты перешел на оскорбления. Что дает мне право считать, что ты просто меня оболгал.

> Я не гуру PHP, это точно, но что-то знаю.

Ага, что-то знаю, и что-то оценю, да? Ну, так, плюс-минус туда-сюда ;)

>>А ведь я тебе явно объяснял что реляционные модели могут зависеть от
>>конкретной б.д. И дело не в оракле. Следи за темой.

>Ну да, а значит пример с nested sets-ами был не в кассу? Пример-то про
>фичи БД был, а не про интерфейс с СУБД?
Пример в кассу. Пример к тому, что наличие интерфейса к БД не решает проблем, а иногда даже создает дополнительные и наличие разрозненных функций для работы с бд, как это есть в ПХП, иногда большой плюс. Ты элементарно не образован, поэтому не можешь вкупиться в ответы которые тебе дают.

>>Потом я понял, что ты нифига не рубишь не только в сабже, но и
>>вообще в предмете. Я тебе пару раз намекнул на это, потом пару раз
>>сказал прямо. Потом обозвал быдлакодером. Нуль эффекта.

>Замечательная аргументация...
Это не аргументация, это констатация. 8(

>>Я как тупой пхп-кодер официально заявляю, что хоть ты и якобы пишешь
>>на жабе, ты тупой, мирный даун. Ты нихрена не понимаешь ни в теме
>>топика в который влез, ни в предмете вообще. Вали читать мурзилку
>>придурище.

>Слив засчитан.
Читать, как "Да дяденьга, я понял, что я домбоеб"? Ты вдаешься в смысл фраз которые копируешь у других?

Судя по твоим репликам, ты именно не знаешь в php ничего, далее уровня
домохозяек, которых ты ругаешь.

>Ага, что-то знаю, и что-то оценю, да? Ну, так, плюс-минус туда-сюда ;)

Дык так и есть. Слышал же - IBM, дескать, на PHP переходит. Индусов-PHP-шников то много, а аналитиков мало. Приходится вот переквалифицироваться. :)

>Пример в кассу. Пример к тому, что наличие интерфейса к БД не решает проблем, а иногда даже создает дополнительные и наличие разрозненных функций для работы с бд, как это есть в ПХП, иногда большой плюс. Ты элементарно не образован, поэтому не можешь вкупиться в ответы которые тебе дают.

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

> Пример к тому, что наличие интерфейса к БД не решает проблем, а иногда даже создает дополнительные

Ну, мне тоже кажется, что пример не совсем в кассу. NestedSet нормально
реализуется поверх класса доступа к данным. Нет особого смысла их
микшировать. Глянь на PEAR::DB::DB_NestedSet.

> Опять же я не говорил, что интерфейс покроет все возможные фичи, я
> говорил, что основную часть. Например, ResultSet executeQuery(query)
> покрывает уже довольно значительную часть

Але, доброе утро! Ты фразу "разные реляционные модели" понимаешь? Чем тебе поможет твой общий интерфейс, когда у тебя будут разный набор таблиц и работать ты с ними будешь по разному?

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

Это дает тебе право "пойти закопаться в песочнице" (С) Саныч

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

Потрать десять минут _своего_ времени и найди это в гугле.

> Приходится вот переквалифицироваться. :)

Дык учиться надо перед этим. Иначе чем ты отличаешься от тех, кого ты
критикуешь? Им тоже "приходится", и они пишут как могут.

>Але, доброе утро! Ты фразу "разные реляционные модели" понимаешь? Чем тебе поможет твой общий интерфейс, когда у тебя будут разный набор таблиц и работать ты с ними будешь по разному?

Дык это... Я и не предлагал, чтобы через общий интерфейс можно было работать с разными базами одновременно. Я предлагал (грубо) вместо:

mysql_query pg_query и.т.д

использовать

db_query

В твоем случае - это разумеется ничем не поможет. А вслучае кучи поделок на PHP, которым по сути пофиг с какой СУБД работать (используют только простые SELECT-ы, UPDATE-ы, INSERT-ы), будет плюс - можно под несколько СУБД одновременно делать.

Далее мы выяснили, что есть PEAR и AdoDB, который поможет это сделать. Все. Вроде бы проблемы нет.

> Ну, мне тоже кажется, что пример не совсем в кассу. NestedSet
> нормально реализуется поверх класса доступа к данным. Нет особого
> смысла их микшировать. Глянь на PEAR::DB::DB_NestedSet.

PEAR::DB::DB_NestedSet - заточен под майэскуэль третьей версии. И поверь мне, для того чтобы на нем его реализовать, потребовалось довольно изощренные пляски с бубном и множество дополнительных телодвижений.

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

Вещь как бы одна, а на разных бд она реализуется по разному.

> Далее мы выяснили, что есть PEAR и AdoDB, который поможет это сделать. Все. Вроде бы проблемы нет.

Ага, а перед этим ты плевался на PHP за то, что в нём этого якобы нет ;)

>Ага, а перед этим ты плевался на PHP за то, что в нём этого якобы нет ;)

Нет, я плевался на то, что многие пишут не так. А почему пишут - потому что сразу не было.

Я не настолько неадекватен, чтобы утверждать, что на PHP такое в принципе невозможно.

> Я и не предлагал, чтобы через общий интерфейс можно было работать с разными базами одновременно

Ты сказал, что "приложению должно быть абсолютно пофиг на чем работать, на MySQL или на DB2" и сказал ты это в контесте обсуждения JDBC.

>А вслучае кучи поделок на PHP, которым по сути пофиг с какой СУБД
>работать (используют только простые SELECT-ы, UPDATE-ы, INSERT-ы)

А на этот случай добрый анонимус тебе сказал, что можно банально заменить mysql_query на то что там у тебя. семантика у них общая.

Проблема в том, что ты не следишь за темой разговора и гонишь невпопад.

> Нет, я плевался на то, что многие пишут не так. А почему пишут - потому что сразу не было

Тебе русским языком сказали, что Pear есть сразу. Ну что, ты не тормоз после этого?

>Ты сказал, что "приложению должно быть абсолютно пофиг на чем работать, на MySQL или на DB2" и сказал ты это в контесте обсуждения JDBC.

Да, действительно. Я зря это сказал :) Честно скажу - я не имел ввиду все приложения, я имел то, которое у меня в голове было :(

Тем не менее, спорил я против утверждения "единый апи к SQL не есть гуд на самом деле". Именно апи, а не структура/способ работы с базой.

Я рад, что, наконец, мы пришли к некоторому взаимопониманию.

>А на этот случай добрый анонимус тебе сказал, что можно банально аменить mysql_query на то что там у тебя. семантика у них общая.

Это плохое решение. Это решение, бесспорно, но плохое.

>Тебе русским языком сказали, что Pear есть сразу. Ну что, ты не тормоз после этого?

"Сразу не было" - не было на ранних стадиях развития PHP. Я это имел ввиду.

>Проблема в том, что ты не следишь за темой разговора и гонишь невпопад.

Симметрично.

> Тем не менее, спорил я против утверждения "единый апи к SQL не есть
> гуд на самом деле". Именно апи, а не структура/способ работы с базой.

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

> Это плохое решение. Это решение, бесспорно, но плохое

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

> "Сразу не было" - не было на ранних стадиях развития PHP.
> Я это имел ввиду.
На это тебе тоже говорилось, что Pear есть с самых ранних четвертых версий (это более четырех лет назад). А до этого на третьих версиях был phplib который делал почти тоже самое только на третьем пхп.
Третий пхп это как раз и были ранние стадии развития.
Т.е. ты опять пернул без знания фактов.

Скажи мне пожалуйста, по какому вопросу ты еще не обосрался и тя не тыкнули раза три носом?

>Именно по API я тебе привел элементарный пример со вложенными множествами. Когда до тебя чуток доперло, ты резко постарался сменить тему сказав "Дык это... Я и не предлагал, чтобы через общий интерфейс можно было работать с разными базами одновременно". Типа я совсем о другом, а щас опять начинаешь. Ты бы уже не болтался как гомно в проруби а выбрал что-то одно.

Веришь-нет, я с самого начала именно АПИ (доступа к СУБД) и имел ввиду. JDBC, например. Вложенные множества - пример АПИ самой СУБД.

Продолжая пример с JDBC и NestedSets. JDBC - универсальный интерфейс. Что мешает его использовать вместе с, например, Oracle-ом используя фичи Oracle-а? Ничего. Это я и пытался сказать - можно сделать общий АПИ (покрывающий большую часть нужных фич).

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

>Плохое или хорошее, вопрос относительный и зависит от обстоятельств. Просто пернуть "плохое" значит просто пернуть. Ты вроде просил чтобы те тут все аргументировали, а как насчет самого себя?

Хорошо. Одновременно две СУБД так не поддержишь. Ну и просто - зачем создавать себе лишнюю работу? Какое преимущество дает то, что mysql_query и pg_query - разные функции? Я вот этого понять не могу.

>На это тебе тоже говорилось, что Pear есть с самых ранних четвертых версий (это более четырех лет назад). А до этого на третьих версиях был phplib который делал почти тоже самое только на третьем пхп.

Хорошо, тогда это вопрос исключительно образования.

И еще. Вот, например, одна из фраз, с которой я спорил:

>Так что еще не известно что больший костыль JDBC или специфичный набор функций для работы с базой.

Я может тупой, но я так и не понял, чем JDBC мешает работать с постоянно упоминаемыми Nested Sets.

Вот тут ты вообще лоханулся:

>К томуже как грамотному писателю (если ты ся к таким не причисляешь то лучше не суй нам свое мнение а тихо свали в соседний тред как тя об этом уже хором просят анонимусы) те должно быть известно что единый апи к SQL не есть гуд на самом деле. И по хорошему объекты предметной области хорошо бы переводить в реляционные исходя из специфики б.д. дабы полнейшим образом использовать возможности этой самой б.д.

Что такое "АПИ к SQL"? SQL - это язык. К SQL СУБД? Но тогда смотрим фразу выше, про JDBC. Повторю, я так и не дождался, где этот АПИ (который я понял, как АПИ у СУБД, например, JDBC) мешает работать с конкретными фичами конкретной базы?

Это если возвращаться к истокам. Так что нефиг в меня какашками кидаться, сам не ангел.

>(который я понял, как АПИ у СУБД, например, JDBC)

Не "у", а "к", опечатка.

> Я может тупой, но я так и не понял, чем JDBC мешает работать с постоянно упоминаемыми Nested Sets.
Да, ты тупой и тебе не раз об этом сказали. От себя добавлю, что ты еще безграмотный и ленивый.

> Повторю, я так и не дождался, где этот АПИ (который я понял, как АПИ у
> СУБД, например, JDBC) мешает работать с конкретными фичами конкретной базы?

Читай тред ВНИМАТЕЛЬНО я уже три раза объяснял разными словами. Не доходит, твои проблемы.

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

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

Слушай, посленяя просьба. Не дай умереть в неграмотности. Скажи все-таки, где JDBC мешает использовать фичи специфичные для СУБД? (конечно, такие фичи могут быть, но большинство фич JDBC покроет)

Не было такого примера. Так что вынужден перейти на личность - ты балабол.

>Признайся. Тя просто коробит, от того, что какой-то тупой пхп-кодеришка умыл тя - реального жаба-программера. Вот и все. Стыт и срам. Вали отседа и не позорь светлое имя программеров на Java.

Нет, серьезно. Меня не коробит. Мне действительно интересно. Тупым кодеришкой я, кстати, тебя не называл. Я вообще старался уважительно относиться :(

>>Кстати, магический интерфейс вовсе не магический. Какого фига он
>>заставляет программера руками назначать тип данных, когда гораздо
>>надёжнее и очевиднее автоматически брать его из метаданных БД. Ведь
>>типы полей уже определены в таблице. Вывод - данный интерфейс не
>>страхует от человеческой ошибки, как ты утверждал.

>>Да, ты прав. Скажем так, не настолько страхует

Нифига. Если хочется, можешь использовать ***.setObject(Object) в таком случае драйвер за тебя по метаданным будет приводить к типу.

>>Например, он вместо setInt() прописал setString(). Ошибки он не
>>заметит, база тоже строчку схавает без вопросов, а хакер элементарно
>>подсунет в этот код sql-injection.

Фигня. Драйвер все спец. символы экранирует и никакой aql-injection не выйдет. Фигня это всё.

> Слушай, посленяя просьба. Не дай умереть в неграмотности. Скажи
> все-таки, где JDBC мешает использовать фичи специфичные для СУБД?
> (конечно, такие фичи могут быть, но большинство фич JDBC покроет)
> Не было такого примера.

Пример был и объяснения были. Ты просто мыслишь в другой категории, поэтому тебе сложно его увидеть. Я уже объяснил все как мог просто, тебе просто не хватает элементарного образования чтобы понять то что я сказал.
А заниматься твоим образованием я не намерен, уж прости 8)

> Так что вынужден перейти на личность - ты балабол.
Ну и что? Я считаю это своим плюсом. Будучи балаболом я могу лехко общаться и ругаться с очень разными людьми а не только с теми кто ничего кроме JDBC не видели.

> Я вообще старался уважительно относиться :(
Если внимательно перечитаешь тред, ты увидишь, что хамить первым начал именно ты.
Жми урожай.

>Пример был и объяснения были. Ты просто мыслишь в другой категории, поэтому тебе сложно его увидеть. Я уже объяснил все как мог просто, тебе просто не хватает элементарного образования чтобы понять то что я сказал. А заниматься твоим образованием я не намерен, уж прости 8)

Хорошо. Как я это вижу. Есть код работы с Nested Sets. На SQL. Например, на Oracle-овом SQL. Исползуя. Что мешает использовать его через JDBC - хоть убей, не пойму.

Что мне в Google-е то искать?

>Пример сходу. Модель вложенных множеств знаешь? Nested Set которое. Давай изобрази мне, как ты ее одиним и тем же препаредстрингом реалзиуешь выбор ветви в майэскуэле третьей версии и в оракеле?

Вот, например, был предложен код (это не Nested Sets, но почему-то был предложен):

String sql = "select lpad(' ',2*(level-1)) || to_char(child) s from test_connect_by start with parent is null connect by prior child = parent";

PreparedStatement p = conn.prepareStatement(sql);

p.executeQuery();

Что не так? Почему JDBC не подходит?

Вот выборка из таблицы с иерархией, построеной по принципу вложенных множеств (выбрать всех начальников Chuck, я так понимаю):

String sql = "select p2.emp from Personnel p1, Personnel p2 where p1.lft between p2.lft and p2.rgt and p1.emp = 'Chuck'";

Тут вообще обычный SQL. Я в непонятках, честное слово.

Какие другие категории?

Может кто-нибудь все-таки скажет, что не так-то?

> Хорошо. Как я это вижу. Есть код работы с Nested Sets. На SQL. Например, на Oracle-овом SQL. Исползуя. Что мешает использовать его через JDBC - хоть убей, не пойму.

Не "мешает", а "JDBC тебе не поможет". Верхоглядство тя погубит.
Суток не прошло, как ты удосужился слазать в гугель. Правда на половину только.

Сходи терь найди пример, как это делается на MySQL 3.x.x. И потом нарисуй мне как ты реализуешь скажем перемещение ветви из одного места в другое, на оракеле и на мускуле (чтобы были блокировки и все такое).

>Не "мешает", а "JDBC тебе не поможет". Верхоглядство тя погубит.

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

Я не спорю - в сложных случаях он не поможет. Но не помешает. Ты же сказал, что он "костыль".

>Суток не прошло, как ты удосужился слазать в гугель. Правда на половину только.

Ну, справедливсти ради замечу, что я читал статью http://gzip.rsdn.ru/article/db/Hierarchy.xml и раньше, просто там термины английские не упоминаются. Там, правда, Nested Sets в чистом виде нет, но есть частный случай.

>Сходи терь найди пример, как это делается на MySQL 3.x.x. И потом нарисуй мне как ты реализуешь скажем перемещение ветви из одного места в другое, на оракеле и на мускуле (чтобы были блокировки и все такое).

Ну, разный код будет. Разумеется. Но использовать его через JDBC - можно будет.

Я не пытался утверждать чего-то сверхобщего, я просто пытался сказать:

a) Ручной эскейпинг - минус, так как плюсов не дает (аргументы выслушивались), а минус есть.

b) Зоопарк mysql_query, pg_query, etc - аналогично, плюсов не дает, а минусы - есть.

Извини, что потратил столько твоего времени впустую.

>перл - это неудобный и устаревший, полукомпилируемый/полускриптовый, полувеб/полуфигзнаетшто отстой, еоторый никому уже много лет не нужен

О как. То-то за него мне с завидной периодичностью предлагают деньги заказчики. И ведь что интересно, хотят именно перл. Всенепременно хотят. Не иначе антиквары.

>Объясните мне, пожалуйста, почему при сборке apache+php+oracle у меня любая ораклячья функция(ocilogon/oci_connect) с php-скриптах вызывает Segmentation Fault в логах апача?

Объясню только если за тебя за зарплатой прийти можно будет.