А для пассивных? Версий в смысле :)

это означает все ветки, которые сейчас поддерживаются.

конец оракелу

Цитирую: Q: Who is not affected? If application always sends untrusted strings as out-of-line parameters, instead of embedding them into SQL commands, it is not vulnerable. This is only available in PostgreSQL 7.4 or later.

т.е. Если приложение не занимается анонизмом и всегда биндит параметры, то проблемы нет.

Не страшно. В Java давно не видел чтобы кто-то еще не биндил параметры. Да и ORM-библиотеки это делают.

А вот для PHP...

P.S. пофлеймим? :)

> т.е. Если приложение не занимается анонизмом и всегда биндит параметры, то проблемы нет.

С точностью до наоборот.

> С точностью до наоборот.

К счастью ты не прав. Почитай внимательнее, что написано.

Всё, МНЕ КОНЕЦ!!!

>Всё, МНЕ КОНЕЦ!!!

>anonymous (*) (24.05.2006 13:42:06)

Так вот ты какая, Венда!

Зачем этот монстр? Во имя чего? Для большинства задач хватает MySQL и PHP.

> Зачем этот монстр? Во имя чего? Для большинства задач хватает MySQL и PHP.

Во имя Патрика!

А кто знает может ли Посгрес такое?

Тут немного один адепт сначла СКУЭльсервера от микрософт, а теперь адепт Оракела утверждает что в Постгресс нельзя сделать функцию, которая бы строила индекс. Ему вообще то нужен был изначально просто индекс по текстовому полю который выдавал бы NOT NULL если что то есть и NULL если запись пуста. Поиграв в bitmap индекс на оракеле в итоге пришел к тому что надо строить фукнцию которая этот индекс отстроит без введения допполя. Итак может ли оно Постгрес?

>Зачем этот монстр? Во имя чего? Для большинства задач хватает MySQL и PHP.

1. По сравнению с аналогичным по функционалу Oracle, PostgreSQL не такой уж и монстр, а дажы довольно-таки компактный пакет, не особенно требовательный к ресурсам. 2. Привыкши юзать PostgreSQL/Oracle etc. со всеми его "вкусностями" MySQL выглядит поделкой первокурсника. 3. Цитата "Для большинства задач хватает MySQL". Теперь представим ситуацию, что Ваш проект возымел успех и вырос до масштабов, что уже MySQL не не хватает. Ваши действия. Портировать? Всё переделывать? Иногда бывает вообще проще всё переписать заново... Типа "настоящие мачо не ищут лёгких путей" :)

а вы когда последний раз видели mysql? году в 1999 наверное?

>2. Привыкши юзать PostgreSQL/Oracle etc. со всеми его "вкусностями" MySQL выглядит поделкой первокурсника.

+1

>2. Привыкши юзать PostgreSQL/Oracle etc. со всеми его "вкусностями" MySQL выглядит поделкой первокурсника.

>+1

Точно! Слон форевер!

> Привыкши юзать PostgreSQL/Oracle etc. со всеми его "вкусностями"

классно к ораклу примазались.

а когда в постгресе сделают нормальную поддержку collations? (в mysql кстати давно уже есть)

>а вы когда последний раз видели mysql? году в 1999 наверное?

А что он с тех пор научился делать кроме тривиального SQL?

Попробовал недавно поюзать сабж вместо MySQL. Задачи у меня скромные.
Всё устраивало, кроме одного: при выполнении функции LIKE('string%') постгресс различает lower-case и upper-case.
А в mysql с case-insensitive collation всё красиво и радостно :)
Так что остался со своими баранами.
Да и софта поддержки у MySQL побольше, популярность однако.

мля как поработаешь с нативным mysql клиентом, жить не хочется

>Всё устраивало, кроме одного: при выполнении функции LIKE('string%') постгресс различает lower-case и upper-case.

а upper,lower отменили?

> Всё устраивало, кроме одного: при выполнении функции LIKE('string%') постгресс различает lower-case и upper-case.

Я тоже как то хотел купить мерседес и не нашел как там свет в салоне включать, пришлось остаться со своим запорожцем.

А если по теме: смотри функцию ilike, читай документацию: http://www.postgresql.org/docs/8.1/interactive/functions-matching.html#FUNCTI... и ваши волосы будут гладкие и шелковистые

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

А нормальные люди пишут системы, как минимум, с драйвером БД, как максимум - используя готовые БД-независимые API.

И только первокурсники продолжают писать в своих .php "mysql_query(...)".

ну или x ~* 'string.*'

>Зачем этот монстр? Во имя чего? Для большинства задач хватает MySQL и PHP.

Для большинства *ваших* задач. Когда подрастете и выйдете из возраста сайтов "Я и моя собака", вот тогда и поговорим.

Разводить VS здесь бесполезно, Вы не поймете.

>а вы когда последний раз видели mysql? году в 1999 наверное?

Хорошо. Берем MySQL образца 2006 года.

- FULLTEXT не работает в InnoDB, Foreign Keys не работает в MyISAM
http://dev.mysql.com/doc/refman/4.1/en/fulltext-search.html

- VIEWS Куча ограничений
http://dev.mysql.com/doc/refman/5.1/en/create-view.html

- Язык хранимых процедур - один, ХП, написанные на нем, регулярно
выносят сервер.

- Репликация падает, если на ведущем сервере возникает ошибка
http://dev.mysql.com/doc/refman/5.0/en/replication-features.html

Список можно продолжать....

Никто не говорит о том, что MySQL *нельзя* использовать. Можно, но
только в достаточно узком кругу задач. Сравнивать с PostgreSQL 
нельзя -- потому, что более-менее корректное сравнение можно сделать 
с версией 7.0.X, которая была актуальна шесть лет назад (сейчас 
актуаальна ветка 8.X).

Дополнение.

Разумеется, можно написать проект безо всяких там FOREGN KEYS, CHECKS, TRIGGERS и VIEWS. Можно вынести всю бизнес-логику во внешний обвес базы и каждый раз по требованию клиента пересобирать весь проект заново. Можно обойтись без DATA PARTITIONING просто купив железо помощнее. Совсем хорошо если не нужен механизм асинхронных событий.

Это все можно. Но вот почему-то никто из серьезных разработчиков так не делает.

Не могу понять, чем разработчикам не понравился Сишный способ экранирования спец-символов, при помощи слеша?

Нет. Вы меня не поняли :) Конечно я юзал ILIKE. Но оно не позволяло мне юзать индексы. А для таблицы с ~ миллионом строк это катастрофично.
Цитирую сайт постгресса:

It is also possible to use B-tree indexes for ILIKE and ~*, but only if the pattern starts with non-alphabetic characters, i.e. characters that are not affected by upper/lower case conversion.

(c) http://www.postgresql.org/docs/8.1/interactive/indexes-types.html

Может я и тут что-то недопонял? :)
Мне надо делать выборку по полю CHAR(64) вида 'string%' где string обычно длиной от 3 до 10 символов. Кодировка вендовая.

>как максимум - используя готовые БД-независимые API

Конечно если не выходит за рамки банальных селекто-инсертов-адейтов-делейтов и при девелопменте серёзно задумываться о том, что же такое умеет делать PosgreSQL/BD2/MS-SQL чего не умеет MySQL, то да можно получить абсолютную переносимость... правда в ущерб возможностям и иногда эффективности.

>Это все можно. Но вот почему-то никто из серьезных разработчиков так не делает.

Именно так. В реальности возможно понадобится переносить системы между db2/oracle/ms-sql/postgresql (что я многократно наблюдал и в чём дажы участвовал) но переносить проекты из оных в MySQL(!) думаю вряд ли кто серъёзно отважиццо :)

>правда в ущерб возможностям....

Так какие там возможности то в mysql?

> Не страшно. В Java давно не видел чтобы кто-то еще не биндил параметры. Да и ORM-библиотеки это делают.

> А вот для PHP...

> P.S. пофлеймим? :)

Фигли с бараном флеймить? Ему на на лбу надо написать о том, что всё
это есть в php много лет, и заставить чаще смотреться в зеркало.

А что, в postgresql нормально работает fulltext из коробки?
И репликации появились? Давно ли?
Views и ХП - излишество. БД должна качественно хранить и быстро отдавать
данные. Всё остальное - забота сервера приложения (AS).

>А что, в postgresql нормально работает fulltext из коробки? Вообще-то да... откройте для себя contrib/tsearch2. Полнотекст в мыскле и рядом не валялся

>И репликации появились? Давно ли? Не поверите - давно. И не одна, а несколько... Правда, извините, не из коробки - и слава Богу.

>Views и ХП - излишество. БД должна качественно хранить и быстро >отдавать данные. Всё остальное - забота сервера приложения (AS). Для того, чтобы хранить, надо их туда еще положить... что там насчет транзакций, ссылочной целостности - давно ли появились?

>Views и ХП - излишество. БД должна качественно хранить и быстро отдавать данные. Всё остальное - забота сервера приложения (AS).

Ну-ну. А если данных апофигительное количество? Ты на AS их все выгребешь чтобы про апдейтить то что может сделать обычный триггер в 3 строки? Слушай тема - WHERE CLAUSE тоже лишняя вещь (это в тему вьюшек). Нах он сдался - усе пофильтруем в middle tier. А база пусть хранит и отдает....

>Так какие там возможности то в mysql?

Возможности вполне подходящие для написания простых проектов. И в некоторых случаях выбор MySQL - единственнно правильное решение.

Другое дело, что сейчас MySQL усложняется в ущерб производительности, что очень и очень плохо. Потому, что чудес не бывает и скорость от версии к версии будет только снижаться, а догнать и перегнать Оракл/MSSQL/DB2, да и тот же Постгрес не получится.

>А что, в postgresql нормально работает fulltext из коробки?

Вообще-то да... откройте для себя contrib/tsearch2. Полнотекст в мыскле и рядом не валялся

>И репликации появились? Давно ли?

Не поверите - давно. И не одна, а несколько... Правда, извините, не из коробки - и слава Богу. Хотя, если хотите реплицировать весь кластер - милости просим, работает из коробки

>Views и ХП - излишество. БД должна качественно хранить и быстро >отдавать данные. Всё остальное - забота сервера приложения (AS).

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

>А что, в postgresql нормально работает fulltext из коробки?

Работает.

>И репликации появились? Давно ли?

Лет пять назад.

>Views и ХП - излишество. БД должна качественно хранить и быстро отдавать данные. Всё остальное - забота сервера приложения (AS).

Беда только в том, что *качественно* хранить при отсутствии нормального механизма контроля ссылочной целостности не получится. А механизм этот базируется на CONSTRAINTS, CHECKS, TRIGGERS и FOREIGN KEYS. И если всех этих механизмов нет или они работают плохо, то база - уже не база, а каша из данных, никак не связанных друг с другом. И любая ошибка в такой базе не подлежит детектированию.

А вообще, меня радуют фанатики MySQL. Пока в их любимой СУБД не было FOREIGN KEYS, на форумах, списках рассылки и даже на mysql.com, везде короче, писалось, что внешние ключи нафиг не нужны. Тоже самое было и с транзакциями; утверждалось, что LOCK TABLE отлично заменяет работу транзакции (каково, а?). Как только эти механизмы прикрутили, всем стало совершенно очевидно, что это прекрасно.

Уверен, как только народ доведет ХП, VIEWS и триггеры, ВЕЗДЕ будет написано о Великом Прорыве В Разработке СУБД.

Примерно тоже самое, когда на Опель ставят датчик дождя и рекламируют на каждом углу как МегаНовуюФичу,хотя на тех же BMW он ставится с 1978 года как.

я вот честно не понимаю зачем нужен mysql, если есть sqlite...
ИМХО одно о и тоже... (тока sqlite по масштабируемее будет)

> Конечно я юзал ILIKE. Но оно не позволяло мне юзать индексы

А разве mysql позволяет?

>Мне надо делать выборку по полю CHAR(64) вида 'string%' где string обычно длиной от 3 до 10 символов.

Если нужно сделать выборку по этому полю с помощью ilike введите еще одно поле в котором будете хранить lower(ПОЛЕ) и делайте по нему индекс, а затем like по этому новому полю - вот и все.

>>Мне надо делать выборку по полю CHAR(64) вида 'string%' где string обычно длиной от 3 до 10 символов.

>Если нужно сделать выборку по этому полю с помощью ilike введите еще одно поле в котором будете хранить lower(ПОЛЕ) и делайте по нему индекс, а затем like по этому новому полю - вот и все.

А можно проще: сделать индекс по lower(ПОЛЕ) и в выборке делать lower(ПОЛЕ) like 'string%' - должен использоватьс индекс

>Для большинства *ваших* задач. Когда подрастете и выйдете из возраста сайтов "Я и моя собака", вот тогда и поговорим.

Сайты "я и моя собака" и есть большинство задач. Естественно, речь идёт о количестве.

>FULLTEXT не работает в InnoDB

А в Postgre появился FULLTEXT?

>если есть sqlite...

sqlite потянет на средней машине 1000 конкуррирующих запросов в секунду, из которых 60% SELECT и 40% UPDATE?

> Слушай тема - WHERE CLAUSE тоже лишняя вещь (это в тему вьюшек). Нах он сдался - усе пофильтруем в middle tier.

О, проснулся. Жабокодеры именно так и делают.

>>А что, в postgresql нормально работает fulltext из коробки?
>Работает.

Не верю (c). Хотя... всё развивается. Со временем и у слона крылья
могут вырасти.

>>И репликации появились? Давно ли?
>Лет пять назад.

За мегабаксы? Не интересно. Незачот.

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

Ну и кто мешает осуществлять такой контроль на уровне AS? Не убедил.

> Пока в их любимой СУБД не было FOREIGN KEYS, на форумах, списках рассылки и даже на mysql.com, везде короче, писалось, что внешние ключи нафиг не нужны.

А что изменилось? Они и сейчас как пятое колесо в тележке...

>А в Postgre появился FULLTEXT?

Несколько лет как. То, что Вы о нем не знаете, не означает, что его нет.

>Ну и кто мешает осуществлять такой контроль на уровне AS? Не убедил.

То, что любая ошибка в AS будет НЕИСПРАВИМА и данные придут в СУБД неконсистентными. В отличие от взрослых баз, где неконсистентные данные просто не будут приянты.

>А что изменилось? Они и сейчас как пятое колесо в тележке...

Конкретно для Вас - ничего.

>>Лет пять назад.

>За мегабаксы? Не интересно. Незачот.

За 0.000$. Лежит в contrib. Безо всяких мегабаксов.

Короче, граждане спорщики! Сначала прочитайте про то, что Постгрес умеет, а только потом тупите на ЛОРе. Ей-богу смешно, те, кто использует Постгрес знают о недостатках как Постгреса, так и Мускля, а фанатики MySQL только и умеют что просто вопить.

>А что изменилось? Они и сейчас как пятое колесо в тележке...

Судя по всему, Вы не представляете для чего нужны FK. Не представляйте дальше.

Некоторым вредно не только высшее образование но и начальное.