LINUX.ORG.RU

Вышел PHP 5


0

0

13-го июля было объявлено о выходе первой стабильной версии PHP 5. Новая ветка содержит большое количество изменений и улучшений по сравнению с PHP 4, призванных приблизить PHP по мощности к таким языкам, как Java и C#. Ключевые новшества в новой версии:

- движок Zend Engine II, с полноценной поддержкой ООП и многими другими языковыми новшествами

- полностью переписанная поддержка XML, основанная на libxml2

- новое расширение SimpleXML, позволяющее работать с XML как с набором PHP-объектов

- встроенная поддержка SOAP для создания и использования Web-сервисов

- новое расширение MySQLi для работы с MySQL 4.1; помимо традиционного процедурного, предоставляет также и объектно-ориентированный интерфейс, и поддерживает множество новых возможностей ветки 4.1, таких, как prepared statements

- встроенная поддержка SQlite

- значительно улучшен API потоков, в частности, теперь имеется возможность использовать низкоуровневые операции с сокетами

Список изменений по сравнению с RC3: http://www.php.net/ChangeLog-5.php#5.0.0

Скачать: http://www.php.net/downloads.php#v5

>>> Анонс на PHP.NET

★★★★

Проверено: Demetrio ()

Ответ на: комментарий от annonymous

> Блин, какая разница, объясни на милость? В чём _существенное_ отличие
> поддержки проекта на perl и на php? Ответь, пожалста, на этот вопрос.
Ну maintain-ить 2 тысячи PHP функций это не одно и то же что maintain-ить 100-200 объектов на Perl-е. Про объекты в PHP4 лучше не упоминай. PHPUnit последний раз апдейтился 2002-3-27 и явно не отражает текущее состояние PHP. Может есть ещё какие testing framework-и для PHP современные ? А ведь без unit test-ов о какой maintanability можно вообще говорить ?

> Бить будем не сильно, но больно ;)
Главное что бы отдача не замучила :)

> Нет, отсюда другой вывод! Ты ещё очень мал, не писал больших проектов
> на perl и просто не знаешь perl ;) Если б знал, то закусил бы губу.
> В perl'е не меньше проблем с переносимостью от версии к версии.
Не мне, но отвечу. Никаких проблем с переносимостью если внимательно читать, что experimental, что obsolete, а что можно юзать без проблем. По крайней мере я не встречал с 5.6.0 до 5.6.4

nuBo
()
Ответ на: комментарий от nuBo

что-то я не понял если пхп так тяжело супортится то почему крупнейшие ресурсы инета частенько крутятся на пхп ? покажите хоть один крупный ресурс нп перле, с милионами поситителей в день ?

еще совсем не понятно как это "maintain-ить 100-200 объектов на Perl-е" почему тучи народу считают что перл write fast read slow ?? Тот же yahoo крупнейший ресурс грит что на перле тяжело maintain-ить.

anonymous
()
Ответ на: комментарий от int19h

У PHP namespace отсутствует как явление.
В отличие от перла, принудительного ограничения видимости переменных нету, AFAIK. То же относится и к видимости функций.

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

Zulu ★★☆☆
()

вообще, честно говоря, мне как php-девелоперу со стажем (начинал с php3), в php5 ничего особенного, чтобы на него переходить, не видно (хотя, конечно, придется со временем :-) ). ООП, который меня вполне устраивал был и в php4. Новое расширение mysqli все-равно не интересно пока не выйдет стабильная версия mysql 4.1. А то, что некоторые, особо продвинутые типы, начнут юзать sqlite меня тоже не воодушевляет, потому что приблуда которая не умеет делать alter таблицы без её полного удаления для серьезной работы не годится (и это не единственный ее недостаток).

По поводу перла. Читал книжку Водолазкого/Семерикова по Перлу, хотя ничего серьезного не нем не написал, и IMHO этот язык гораздо менее логичный чем php, хотя и имеет свои плюсы - на нем можно писать гуй (хотя на php тоже есть интерфейс к gtk, но это IMHO изврат, php годится только для веба и консоли). Нелогичность заключается в необходимости изучения большого кол-ва разных способов написания (а также большом грузе устаревших, хотя php тоже этим грешит - синтаксис php/fi), а также в использовании переменной по умолчанию. Кстати, при переходе с perl4 на perl5 AFAIK было тоже много гимора. О переходе с Asp на asp.net я вообще молчу - это разные языки.

anonymous
()
Ответ на: комментарий от anonymous

да.. единственный недостаток в php - отсутсвие локализации для некоторых функций (приходилось самому искать ф-ии в инете с поддержкой русского или писать самому).

anonymous
()
Ответ на: комментарий от anonymous

> покажите хоть один крупный ресурс нп перле, с милионами поситителей в день
amazon.com

> почему тучи народу считают что перл write fast read slow ??
потому что они на PHP пишут. PHP - write fast, unable to read. Чего стоят только разный порядок параметров к функциям работы с бд, это просто п@#$ц.

> Тот же yahoo крупнейший ресурс грит что на перле тяжело maintain-ить.
Смотри сюда, эта ссылка пробегала уже (помни, это 2002 год):
http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm

И что мы имеем ? Что YSP уделал PHP (кроме памяти, что кстати ещё под вопросом, ибо хез как они писали), к тому же YSP судя по всему какой-то framework (не нашёл чет про него ничего), если pure mod_perl использовали выжали бы ещё %20.

Ты понимаешь как принимается решение о выборе платформы? В нормальной компании это решение принимают программеры (не важно, внутренние или внешние подрядчики). Вообще технические решения должны принимать программеры. Соотвественно, программеры выбирают то, на чем им *кажется* легче и быстрее писать. Не многие из них знакомы с unit testингом. Может PHP похож на yScript2. PHP программеры дешевле чем Perl. Эйфория от нового "простого" языка для web скриптинга. А на perl-е они не знали ничего про template framework-и. Вобщем нормальное решение принятое программерами. Другой вопрос - правильное ли ?

nuBo
()
Ответ на: комментарий от annonymous

> В perl'е не меньше проблем с переносимостью от версии к версии.

Большой проект на mod_perl + Template Toolkit. Проблем при переходах от 5.6.1 до 5.8.4 не было.

Vond ★★
()
Ответ на: комментарий от nuBo

>потому что они на PHP пишут. PHP - write fast, unable to read. Чего >стоят только разный порядок параметров к функциям работы с бд, это >просто п@#$ц.

я не знаю может это ты про какой-то очень новый перл, но бля помнится сдесь уже было офигеный флейм когда кекс запостил перловую строчку, типа почему не работает, а там rm -rf / :) тут кача горя програмеров воздух сотрясала, судами угражала :)
так вот yahoo (кексы покруче тебя) считает что у перла такие минусы:

– There’s More Than One Way To Do It

– poor sandboxing, easy to screw up server

– wasn’t designed as web scripting language

на счет параметров к функциям - хочешь однообразия, используй стандартные PEAR::DB, ADODB и прочее.
и еще, перл умеет компилится в байткод ? умеет работать как модуль апача или только cgi ? а то на счет скорости тестов нормальных не видел, но не онимаю что может позволить перлу выйграть в скорости.

anonymous
()
Ответ на: комментарий от eXOR

> > проблемы с масштабируемостью: 3-хзвенной архитектурой тут и не пахло.

> Гм... язык тебе позволяет сделать из него все что хочешь. От какашки, до конфетки.

Ну попробуй, реализуй для PHP хотя бы треть функционала J2EE.

Или просто не знаешь, о чём говоришь?

P.S. Для Perl и то никто пока не сделал ничего подобного 3х-звенной архитектуре, хотя некоторые тендеции есть (OpenInteract, как мне кажется, примерно в том направлении идёт). А уж для PHP и подавно... :)

Vond ★★
()
Ответ на: комментарий от eXOR

> > проблемы со скоростью: тормозит не по детски.

>Отличный критерий. Можно сравнительную характеристику? Идеально ссылочку с тестами.

Дали уже ссылку - на слайды Yahoo. Там в конце есть результаты сравнения PHP 4.1.2 (w/Accel), yScript2 (proprietary) и YSP (mod_perl). Так вот по их тестам обгоняет всех YSP, использующий mod_perl. Ну памяти разве что чуть больше тратит, но ведь, как говорится, "memory is cheap" :)

Vond ★★
()
Ответ на: комментарий от Vond

>Ну попробуй, реализуй для PHP хотя бы треть функционала J2EE.

для веба у пхп функционала гораздо больше, J2EE тормоз и обсолютно бесполезная технология для веба с простенькой логикой.
лучшеб они вместо наворотов SWT доделали, а то бля GUI на свинге или авт это вершина тормознутости.

anonymous
()
Ответ на: комментарий от int19h

> > проблемы с масштабируемостью: 3-хзвенной архитектурой тут и не пахло

> А с каких пор _язык_ обеспечивает поддержку архитектуры? Я думал, это задача framework... и соответствующие наработки для php есть. Гугль - друг человека!

Это, конечно правильно. Теоретически :) А фактически ни для перла, ни, тем более, для PHP, нет framework'ов, позволяющих использовать 3-хзвеннную архитектуру.

Vond ★★
()
Ответ на: комментарий от anonymous

> для веба у пхп функционала гораздо больше, J2EE тормоз и обсолютно бесполезная технология для веба с простенькой логикой.

Ага. Полностью согласен. Для "веба с ПРОСТЕНЬКОЙ логикой". Вот это и есть ниша PHP. Охотно верю, что весьма большая ниша :)

Vond ★★
()
Ответ на: комментарий от anonymous

>Умеет работать как модуль апача или только cgi ?

Вот он - уровень php программера, человек даже про mod_perl не знает.

chucha ★★★☆
()
Ответ на: комментарий от chucha

> Вот он - уровень php программера, человек даже про mod_perl не знает.

На самом деле, это плюс php-программеров. Стоят они дешевле (хотя бы по оценкам Yahoo: "doesn’t require CS degree to use")

Vond ★★
()
Ответ на: комментарий от anonymous

> There's More Than One Way To Do It
так это же хорошо !!! Хуже когда there's no way to do it: в php только только появились сокеты и fork-и.

> poor sandboxing, easy to screw up server
ну это про их руки кривые, а не про perl

> wasn't designed as web scripting language
это не значит что с web scripting-ом на perl-е
есть какие-то проблемы. Только в воспалённом воображении anonymous-ов разве только

> умеет работать как модуль апача или только cgi ?
и это чмо спорить будет со всеми, не зная элементарных вещей ??? в сад

> перл умеет компилится в байткод
а что, это как-то влияет на performance ? Умеет

> а то на счет скорости тестов нормальных не видел, но не онимаю что может позволить перлу выйграть в скорости.
Это потому что ты задаешь вопросы "умеет ли работать как модуль апача". Вобщем иди сначала мануалы читать, а то бздишь в лужу (BSD тут не причём ;-)

nuBo
()
Ответ на: комментарий от chucha

>Вот он - уровень php программера, человек даже про mod_perl не знает.

да я не знаю перл ...
я заню oracle. мне полностью хватает пхп для веба, практически вся логика это pl/sql. еще есть oracle portal - а это пиздец. чтоб сделать элементарный портлет нужно столько мышой юлозить в бровсере что под конец виндовс с его ХР уже не кажется таким уж Х. а если попытатся выяснить что там под iAs и portalом делается бесполезного, вообще швак. если не нужны SOAP, EJB и т.п. j2ee бесполезная технология в вебе.

anonymous
()
Ответ на: комментарий от nuBo

> Ну maintain-ить 2 тысячи PHP функций это не одно и то же что maintain-ить 100-200 объектов на Perl-е.

И каким образом ты maintain-ишь 2 тысячи PHP функций в реальном проекте?
Поделись опытом. Но сначала скажи, зачем это нужно.

> Про объекты в PHP4 лучше не упоминай.

Про объекты в perl лучше не упоминай.

> PHPUnit последний раз апдейтился 2002-3-27
Это ты опять соврал.
1.0.1 (stable) was released on 2004-04-17
http://pear.php.net/package/PHPUnit

> Главное что бы отдача не замучила :)

Дык нет отдачи. Слышны только лёгкие покашливания.

> Никаких проблем с переносимостью [...] По крайней мере я не встречал с 5.6.0 до 5.6.4

Мало живёшь на свете этом ;) Проблемы были и серьёзные при переходе
с 5.004 на 5.6.0.

annonymous ★★
()
Ответ на: комментарий от Vond

> Проблем при переходах от 5.6.1 до 5.8.4 не было.

Проблем при переходах от php-4.0.6 до php-5.0 так же не было.
О чём спорим-с?

anonymous
()
Ответ на: комментарий от anonymous

> если не нужны SOAP, EJB и т.п. j2ee бесполезная технология в вебе.

EJB - это да, вещь краеугольная. А что, без J2EE без EJB так уж прям совсем безполезен? Я вот думаю, то, что позволяет делать Struts на Tomcat'e, на mod_perl делать сильно дольше. Точнее, я не знаю нормальных фреймворков для mod_perl, готовых к production.

Vond ★★
()
Ответ на: комментарий от nuBo

>> There's More Than One Way To Do It
> так это же хорошо !!! Хуже когда there's no way to do it

Ты даже не представляешь себе, какой это ужас и ночные кошмары!
Лучше вообще не иметь ничего, чем это уродство. Я серьёзно.
Лучше на bash программировать.

> > poor sandboxing, easy to screw up server
> ну это про их руки кривые, а не про perl

Ты хорошо понял, что такое sandbox?
Проблема в твоём рассуждении заключается в том, что sandbox к рукам
не только не может, но и не должно иметь никакого отношения ;)
Это свойство интерпретатора - возможность сужать степень свободы
программиста и приложения для обеспечения необходимого уровня
безопасности.

> это не значит что с web scripting-ом на perl-е есть какие-то проблемы.

Есть дополнительный костыль, если выражаться точнее... А так,
теоретически можно и на самосвале надстроить вагончик и представлять
его как эксурсионный автобус ;) Функциональность будет почти полностью
соблюдена...

annonymous ★★
()
Ответ на: комментарий от chucha

>EJB - это да, вещь краеугольная. А что, без J2EE без EJB так уж прям >совсем безполезен?

нет, не бесполезен, но просто не имеет преимуществ. + медленее, и много больше кода писать. у Java поддержка покруче, но оракл щас пхп в iAs супортит и мне для галочки этого хватает.
а MVC фреймворков для пхп пруд пруди.

anonymous
()
Ответ на: комментарий от annonymous

> И каким образом ты maintain-ишь 2 тысячи PHP функций в реальном проекте?
слава богу никаким. А вот на perl-е 100 объектов при помощи unit test-ов. Причём запросто.

> PHPUnit последний раз апдейтился 2002-3-27
> Это ты опять соврал.
это ты батенька врёшь, потому что не "опять", а первый раз. А во вторых не соврал, ибо смотри на phpunit.sf.net.

> Мало живёшь на свете этом ;) Проблемы были и серьёзные при переходе
с 5.004 на 5.6.0.
Пример в студию ?

nuBo
()
Ответ на: комментарий от anonymous

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

ЗЫ. Но синтаксис перла ужасен (то есть, красивый, но на любителя), я на нем пишу только когда на меня охота стихи писать находит, и fusion jazz слушаю при этом... А так, ПХП меня устраивает, когда кучу текста не надо парсить.

IMNSHO
()
Ответ на: комментарий от Vond

> Пытаюсь объяснить, что не всё так просто, как кажется адептам PHP.

Ты не пытайся, ты чётко сформулируй свои тезисы. Я пока что не увидел
здесь ни одного серьёзного аргумента, чем плох PHP. Он используется
в своей нише, никого не трогает и ни у кого хлеб не отбирает. Для веба
он _оптимален_. Знаешь это слово? Это не хначит, что он лучше всех
работает с какими-то определёнными перечисленными тут функциями.
Это значит, что в общем и целом он оказывается предпочтительным при
прочих равных условиях. Скорость, стоимость разработки, лёгкость
обслуживания, доступность программистов и т.д.

annonymous ★★
()
Ответ на: комментарий от annonymous

Воистину, оптимизировать код хорошо, а оптимизировать труд программиста -- оптимально...

IMNSHO
()

и пхп и перл сосут по своему. ява со своей статической типизацией для неслишком сложных вещей - трата времени (что пхп с weak dynamic typing к java/c# приближается, это вообще перл [каламбур?]). жаль что питон не занял вовремя свой заслуженой доли в нише веб языков, язык гораздо более правильный. на пхп писать можно, но неприятно как то после питона..

anonymous
()
Ответ на: комментарий от Vond

> Ну попробуй, реализуй для PHP хотя бы треть функционала J2EE.
Какого именно? И какую треть? Ты вообще понимаешь о чем ты? Какую из метрик будем применять чтобы определить треть?


> Или просто не знаешь, о чём говоришь?
Походу ты не понимаешь и вообще не в состоянии вкурить. API != язык... архитектура твоего приложения != язык... если сравнивать платформы php4 и J2EE то это, $#%ть инструменты ориентированые на разные рынки.

> А уж для PHP и подавно... :)
Не видел и видеть не хочу? А так как не видел - то значит и нет?

eXOR ★★★★★
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от annonymous

> Для веба он _оптимален_.
Видимо у нас разные понятия слова _веб_. Для тебя веб - это хоумпейдж с phpBB. Для меня - это lj, slashdot. Slashdot effect слышал ? Что то они не спешат на php, хотя он весь такой пушистый.

> не увидел здесь ни одного серьёзного аргумента, чем плох PHP.
А он хорош для хоумпейджей. Никто не спорит. Только perl лучше.

nuBo
()
Ответ на: комментарий от nuBo

> это ты батенька врёшь, потому что не "опять", а первый раз.

Нет, на самом деле ты всё время врёшь, в каждой фразе. Можно это,
конечно, мягко назвать "тенденциозными заявлениями", но лучше называть
вещи своими именами.

> с 5.004 на 5.6.0. Пример в студию ?

Глянь perldelta. Большие приложения без напильника не пускались.
Не спрашивай точные подробности. Всё-таки несколько (4-5) лет назад это
было. Не запоминаю я плохое ;) В 5.00x был ужасный мemory leak при
работе c hashes. Эта проблема просто жёстко форсировала переход на
новую версию. Вот линк на тред остался в закладках: http://sourceforge.net/forum/message.php?msg_id=184150
Там сначала грешили на прогу, а оказалось, что глючит perl...

annonymous ★★
()
Ответ на: комментарий от nuBo

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

IMNSHO
()
Ответ на: комментарий от nuBo

> Для тебя веб - это хоумпейдж с phpBB. Для меня - это lj, slashdot.

Опять ты соврал. Для меня web-приложение - это как минимум что-то класса
CMS, CRM. Slashdot? Нет, это пионерская развлекуха. Пример смешон до
безобразия. Может ещё ЛОР объявишь крутым серьёзным проектом? Всё к тому
идёт...

> Slashdot effect слышал ? Что то они не спешат на php

Можешь расслабиться. Perl прогнётся под Slashdot эффектом точно так же,
как php. Но первым сдохнет проект на java или python ;) Ты хорошо понимаешь, о чём ты говоришь? Я глубоко сомневаюсь.

annonymous ★★
()
Ответ на: комментарий от anonymous

> По поводу перла. Читал книжку Водолазкого/Семерикова

А ты не читай туфту всякую. Читай книжку Ларри Уолла. Благо по-русски уже давно издали.

vitus
()
Ответ на: комментарий от annonymous

> Нет, на самом деле ты всё время врёшь, в каждой фразе.
Пример в студию

> Глянь perldelta.
Единственно важная (которая ломала *криво написанный* код) incompatibility там была с тем что хэши в delete(), each(), values() стали работаеть не с копией, а с alias-oм. Но это по любому bad style удалять элементы из хэша по которому итерируешь.

> В 5.00x был ужасный мemory leak
Уважаемый, вы сами макаете себя в каку мордой лица. Вы же говорили про совместимость при миграции с 5.0 на 5.6. Причём здесь memory leak ???

nuBo
()
Ответ на: комментарий от nuBo

> Единственно важная (которая ломала *криво написанный* код)

Ну, вот, как и ожидалось пошли отмазки про прямизну рук и т.д.
Прикажете всех расстреливать, чей код после выхода новой версии
вдруг становится "кривым"? А как же пресловутый слоган про "there is
many way how to do it"? ;) Мыльный пузырёк на деле-с... Так или иначе,
приходится предписывать некие стандарты программирования.

> стали работаеть не с копией, а с alias-oм.

А если подумать, кого кроме разработчиков perl'a волнуют эти объяснения?

> Вы же говорили про совместимость при миграции с 5.0 на 5.6.

И что? В чём я не прав? Они на самом деле оказались совместимы? ;)

annonymous ★★
()
Ответ на: комментарий от Zulu

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

Функции с переменными просто красиво так раскладываются по объектам.

int19h ★★★★
() автор топика
Ответ на: комментарий от nuBo

> Чего стоят только разный порядок параметров к функциям работы с бд, это просто п@#$ц.

А может, с PEAR и ADOdb познакомишься? А то расшумелись насчет функций, а кто их реально серьезно использует, кроме как поиграться в первую неделю освоения

int19h ★★★★
() автор топика
Ответ на: комментарий от anonymous

Как это не занял (я про питон и его нишу в вэбе)?! Он как раз занял то, что надо 8). Скоро и тикль с OCaml-ем подтянуться 8). Вобще как прально было сказано надо отделять сами языки от построеных на них фрэймворков (ну или принципов работы в этих фрэймворках).

Из CMS-ов на питоне вспомним уже всех задравшую Zope-у, которая живёт и развивается себе. Предлагаю знатокам PHP и Java привести примеры CMS-ов похожего уровня.

anonymous
()
Ответ на: комментарий от annonymous

> Можешь расслабиться. Perl прогнётся под Slashdot эффектом точно так же, как php. Но первым сдохнет проект на java или python ;) Ты хорошо понимаешь, о чём ты говоришь? Я глубоко сомневаюсь.

Что-то это все мне напоминает мифологию в картинках. :) С чего java или python должны загибаться? :) Насчем последнего могу привести пример ну очень посещаемого сайта (там не порядком тысяч пахнет, гораздо больше). Более того, сайт на Zope - anarchy-online.com :)

Да и на java серьезных нагруженных сайтов немало.

Так что php в этом плане ничуть не лучше. :)

Да, и насчет скорости. По каким тестам java будет тормознее php? Можно это где-то увидеть?

SystemlessDesintegrator
()
Ответ на: комментарий от annonymous

Так где же я врал, ты так и не сказал.

> И что? В чём я не прав? Они на самом деле оказались совместимы? ;)
Именно. Совместимы.

nuBo
()
Ответ на: комментарий от SystemlessDesintegrator

> С чего java или python должны загибаться?

Б данном случае огромную важность имеет прожорливость по памяти.
Тут уже не отболтаешься классической фразой "memory is cheap".
Чтобы комфортно выдержать slashdot effect веб-сервер должен быть
настроен на одновременное обслуживание примерно 5000 соединений.
Ну, естественно, чтоб проводить хоть какое-то достоверное сравнение,
нужно оговориться, что 1) приложения на всех языках примерно одинаковы
по функциональности 2) крутятся на строго одинаковом железе и одной
версии ОС. Если это принять, что хочешь верь, а хочешь посчитай,
java поставит на колени средний современный x86 сервер. Не намного
дальше уйдёт и python ;)

> там не порядком тысяч пахнет, гораздо больше

Не смешите мои тапочки. Какие тысячи? Тысячи запросов он должен
переваривать в секунду, а за день это миллионы ;) Никто в здравом
уме для такого наплыва посетителей Java не поставит ;) Ну, конечно,
маразм не имеет границ, и если он подкреплён миллионными счётами
свободных средств в банке, то можно поставить батарею из серверов
для обслуживания этих запросов. Всё можно при желании...

annonymous ★★
()
Ответ на: комментарий от int19h

> А может, с PEAR и AdoDB познакомишься? А то расшумелись насчет функций...

Родимый, о независимости от СУБД и так только разговоры. Унифицируй поначалу хотя бы синтаксис SQL для всех, а тогда и до функций добирайся. Чего стоит только один мускул со своими причудами...

IMNSHO
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.