LINUX.ORG.RU

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

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

anonymous
()

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

anonymous
()

Цитирую: 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. пофлеймим? :)

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

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

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

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

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

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

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

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

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

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

blaster999 ★★
()

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

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

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

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

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

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

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

>+1

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

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

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

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

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

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

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

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

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

r ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>а вы когда последний раз видели 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).

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

Дополнение.

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

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

anonymous
()

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

KADABRA
()

Нет. Вы меня не поняли :) Конечно я юзал 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 символов. Кодировка вендовая.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Работает.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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