SQLite - это круто, а самое интересное в Бету они забыли включить баги

Я не анонимус - я гость

Что за SQLite? Как же без мускуля?????

http://www.hwaci.com/sw/sqlite/

Что за бред?
действительно как мы без mysql? большая половина сайтов на php именно с привязкой к mysql. кстати какие еще могут быть проблемы лицензионные с mysql???

>поддержка MySQL по умолчанию не включается

вот и смерть пришла PHP

>вот и смерть пришла PHP или MySQL... А действительно что за лажа с лицензиями? Раздуплите плиз

anonymous (*) (2003-06-30 22:31:36.257296):

> вот и смерть пришла PHP

Кому-кому смерть пришла? PHP и без Мыскля юзать можно, а вот кому эта недобаза нужна, если её _по умолчанию_ не ставить? ;

anonymous (*) (2003-06-30 22:53:40.629739):

> А действительно что за лажа с лицензиями? Раздуплите плиз

А чего там раздуплять? Мыскль АБ решили деньжат подзашибить и перелицензировали _клиентские библиотеки_ для новой версии Мыскля с LGPL на GPL. При этом старые библиотеки с новым Мысклем по странному совпадению работать не будут, а новые с PHP распространяться не могут, т.к. он не под GPL, а под близкой к BSD лицензии.

Щас у Мысклеводов состояние "Ё-моё, что ж я сделал-то?"

Интересно, сколько теперь Мыскль АБ протянет?..

PHP 5 и MySQL

А по ссылке сходить не бывает? Там все написано. Программное обеспечение MySQL не может распространяться с открытыми продуктами, которые не идут под GPL или (внимание!) opensource лицензией, утвержденной MySQL AB.
Следовательно, лицензия PHP не была утверждена.

И наконец, речь идет только о клиентской библиотеке MySQL для C, которая издавна прилагалась к PHP, а не о MySQL-расширении. А клиентская библиотека у тех, кому надо, есть и так. Ну, если MySQL на другой машине, можно доставить ее на машину с PHP. Короче, не вижу поводов для воплей.

да, поддержка-то Мыскля там остаётся, просто библиотеки придётся использовать установленные в системе... а вот крутые разработчики, которые пишут свои сайты, используя WAMP (Win98 + Apache + MySQL + PHP), а потом выкладывают их к хостеру за 5 баксов в месяц, сильно обломаны...

nickg (*) (2003-06-30 23:24:58.615274):

> Короче, не вижу поводов для воплей.

Как, а "Call to unsupported or undefined function mysql_connect()" разве не повод для вопля? ;

В общем дело ясное. Жалко конечно Mysql, но PHP пересел на другого конька - SQLite. Не уверен, что это решит проблему набирания веса и громоздкости. Чем дальше, тем более php становится усложненным и обрастает новыми библиотеками. Но приобретая сторонников среди людей многопрофильных, он выходит из среды малых сайтов и малых приложений. Фактически версия CLI уже явилась вмешательством на территорию perl. Не хочу сказать ничего обидного, но perl пока превосходит php и по скорости, и по библиотекам.

Возвращаясь к SQLite - на самом деле это попытка остаться в нише малых сайтов достойна уважения. Сделана она грамотно и почти без ошибок. Ну кому на сайте торговой фирмы (размера четверти Ozon) придет в голову что надо обрабатывать тысячи запросов. Малые сайты как раз характерны множеством selectов и статичной структурой данных. Зачастую они предоставляют собой вообще насмешку над интерактивностью. Лишь поиск по сайту оправдывает звание динамического сайта. В остальных случаях достаточно нагенеренных страниц. Обновления случаются и не так уж часто.

SQLite, ИМХО, подходит к этому случаю предъявляя новые требования к логике построения сайта. Появляютс новые требования оптимизации. Будем надеяться, это повысит качество программирования. В остальном следование моде - XML. Уверен, что многие разработчики остановят свой взгляд либо 4.3.0 либо 5.0, ибо по функциям эти версии уже достигли максимума мыслимого. Все остальное - библиотеки.

помнится игрался я с sqlite (www.sqlite.net) на ipaq - он входит в дистр для наладонников. Удобно конечно - api очень простой, только для веба он слишком прост на мой взляд: управление пользователями нету на пример.

Народ, зачем так кричат ? un-bundled означает что либа доступа перестала поставлять в комплекте сырцов пхп. какого пня кричать так громко и без повода ? все одно, в большинстве дистров пхп собран с общесистемной libmysql.

или "ложки нет, а флейм из рулез" ?

Gor

ничего хорошего, народ вебмастеры прижык уже, стандартом им подавай мускуль+пхп, криков будет, а им самим на их ХеРе теперь как... они же привыкли, бедные...
опять на ОС наедут

а у меня база на PHP+Postgres крутится!

А SQLite действительно легонький-легонький! Проблемы с юзерами на хостинге быть не должно в принципе, поскольку для работы ему нужно просто указать файл. пока нравится :)

>...для тех, кто использует ООП...
ООП - Организация Обьединения Палестины?

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

Если у тебя PIII то базара нет, а ты попробуй эту связку на PI - 166 MHz RAM 32 Mb, ты сразу почуствуешь разницу. MySQL быстрее. Я не говорю что POSTGRESQL is not good. Но по скорости уступает...

Да что вы честное слово прям. Пободаются и перестанут - это они так пробивают свою лицензию в список разрешенных. 99% в релизе 5.0 - MySQL будет.

Да и на самом деле API MySQL встроенное в PHP постоянно отставало от родной либы так что люди с руками все равно собирвли его с внешней библиотекой и дальше будут.

Касаемо SQL-lite. Это замена скорее DBF чем какому-либо из серверов. Работает оно с разделяемым файлом между процессами так что подумайте как там будет со скоростью при хороем concurrency....

Да и выделелнный сервер для базы данных не поставишь.

http://www.sqlite.org/ (очепятка)

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

Да разумется - всему свои применения. Для ряда приложений данные вообще удобнее и быстрее хранить в файле.

Вопрос в том что технология SQLlite очень не масштабируема - шаг в право шаг в лево - грабли.

Вырос размер данных - грабли. (если вы из бенчмак видели то самая большая таблица там 25000 элементов)

Задействованы не тривиальные функции - грабли - погоняйте его на неочевидных join посмотрите :) В benchmark их нет понятное дело.

Захотелось заюзать из других языков - Java, Perl, python - грабли.

Возрасла concurrency - грабли.

Ростет нагрузка и надо переходить на выделенный сервер баз данных или несколько Web Front End - грабли.

Так что я пожалуй буду продолжать компилить внешнюю поддержку SQL а SqlLite пусть пользуют хозяива мелких домашних страничек.

>Да что вы честное слово прям. Пободаются и перестанут - это они так
>пробивают свою лицензию в список разрешенных. 99% в релизе 5.0 -
>MySQL будет.

Хорошо если так.
А если нет то похоже MySQL почти никому не нужен будет.
Ну напрягусь я - один раз перенесу таблицы из MySQL куда
нибудь еще. А то возиться потом - тут PHP c MySQL работает
там не работает да пошел этот MySQL в жопу, буду пользоваться
тем что везде без проблем работает.

> Это замена скорее DBF чем какому-либо из серверов.

Эх, лучше бы они настоящую поддержку DBF/CDX сделали!

> подумайте как там будет со скоростью при хороем concurrency

Со скоростью чтения там просто отлично. Касательно записи тоже
не так все плохо - локировка на уровне строк таблицы имеется.
Скорость записи при одиночных инсертах довольно низкая, но
если их оформить в транзакцию, то выходит даже быстрее, чем у
mysql.

> Да и выделелнный сервер для базы данных не поставишь.

Элементарно, Ватсон. Используй NFS или NBD.

> А то возиться потом - тут PHP c MySQL работает
там не работает

Да везде он будет работать с MySQL. В дистрибутивах вендоры его
соберут c локальной mysql, а в своей установке ты можешь всегда
собрать ручками. Подумаешь, какая беда - сказать
./configure --with-mysql=/usr/local/mysql
Очень сложно, да?

>Да везде он будет работать с MySQL. В дистрибутивах вендоры его
>соберут c локальной mysql,
Ежели дистрибуторы об этом печся будут
то замечательно, тогда покрайней мере
у меня на девелоперской машине все
без проблем будет.
А если нет?
Или под, страшно сказать, виндами что делать?

>а в своей установке ты можешь всегда
>собрать ручками. Подумаешь, какая беда - сказать
>./configure --with-mysql=/usr/local/mysql
>Очень сложно, да?
Ээ нет ребята мне конечно приятно с Linux работать
но не до такой степени. Я вообщето сайт делаю,
мне как бы с сайтом забот хватает.
А косяки за MySQL исправлять у меня ни времени
ни желания нет.

А если нет, то будешь юзать связку php-4.x.x + mysql-3.xx.xx
до конца дней своих. На твой срок этого хватит за глаза.
Нечего за модой гоняться ;)

> Или под, страшно сказать, виндами что делать?

;)) А это личные половые трудности. Пускай их решают те, кто
с виндой работает. Можно, например, пикет организовать у стен
Mysql AB, акцию гражданского неповиновения и т.п.

>А если нет, то будешь юзать связку php-4.x.x + mysql-3.xx.xx
>Нечего за модой гоняться ;)
Дык рад бы - поставить и забыть =)
так всякие security патчи бывают еще.

Проще уж "юзать связку"
php-most_recent + just_working_sql_server(postgre sql например)

>;)) А это личные половые трудности. Пускай их решают те, кто
>с виндой работает. Можно, например, пикет организовать у стен
>Mysql AB, акцию гражданского неповиновения и т.п.
Во во - я и говорю выкинуть MySQL нахрен =)

по опыту - гораздо меньше проблем всегда когда всегда --with-mysql=localpath_to_where_is_mysql_living

Поддерживаю, и довольно неплохо себя чуствует PHP+Postgres, по крайней мере Postgres более похож на базы данных, чем MySQL (особенно тем, кто пересел с Oracle)

> Дык рад бы - поставить и забыть =) так всякие security патчи бывают еще.

Ну это как раз и не проблема. Исправления выпускаются до сих
пор даже для php-3.x. Я держу на нескольких серверах php-4.0.6.
Для него тоже официально заплатки делаются, если находится
дырка.

> php-most_recent + just_working_sql_server(postgre sql например)

Проще для кого? Для домашнего юзера или для держателя хостинга?
Задачи разные, однако. Полноценной замены mysql на массовом
хостинге пока не придумали. Да и не только на хостинге. Если я
сейчас переведу все на postgres, у меня сервера колом встанут
от 40000 запросов в минуту. А для mysql это семечки.

2Troll etc... ...А кто под виндами девелопит - переползайте на Postgres тоже. Правда поначалу скорость разработки типичной (для MySQL) базы данных немного уменьшится, но это проходящее... Ну а затем: "Вечный кайф! (c) Слон"

> Полноценной замены mysql на массовом
> хостинге пока не придумали.

Ну раз хостеры так говорят то пожалуй
я пока не буду сильно переживать, может и впрямь
MySQL еще поживет =)

> Если я сейчас переведу все на postgres, у меня сервера колом встанут
> от 40000 запросов в минуту
бред. по большому счёту, всё равно. у меня конечно нет 40000 з/с(кстати, это ещё вопрос - каких), но наблюдения показывают, что по большому счёту всё равно что стоит - главное чтоб ресурсов хватало и они правильно использовались (sort buffers, WOL у постгреса, log на друго йдиск у MSSQL/Sybase и т.д.). на эту тему есть хорошая статья Тима Пердью - сравнение MySQL vs. Pg. ссылку не помню. по гуглю легко ищется, на пхпбилдере что-ли.
и мускул и постгрес имеют свою нишу, но постгрес масштабируется лучше (на нормальном железе конечно) но имеет больший стартовый порог.

Да да помню ту статью - сравнение допотопного MySQL 3.22 с Postgres кому онон сейчас интересно.

До Innodb, Postgres транзакционной поддержке еще ковылять и ковылять....

anonymous (*) (2003-07-02 00:24:35.890048):

> Если я сейчас переведу все на postgres, у меня сервера колом встанут от 40000 запросов в минуту. А для mysql это семечки.

Хм. А какие это у вас запросы и где? А то 40000 запросов в минуту = ~700 запросов в секунду, а ведь наверное ещё и пики бывают? ;)

anonymous (*) (2003-07-02 09:50:44.070731):

> До Innodb, Postgres транзакционной поддержке еще ковылять и ковылять....

Чуть со стула не упал. Можешь пояснить глубокую мыс(к)ль, что такое умеет InnoDB и чего не умеет Postgres? :]

а от моих 400000000000 запросов в секунду все нахрен рухнет, блин! поэтому я ничего и не ставлю, да и сервак уж давно на помойку снес ибо с моими запросами ни постгрес ни мускуль не справляются, вот! =)

Вопрос не о фичах а о внутренней структуре и из нее растущих последствий Почитай как устроен внутри постгрес и как Innodb и тебе сразу хорошо станет.

Тривиальный пример - попробуй залочить этак 100.000.000 строк в табличке на Postgres, а потом попробуй поменять не залоченые...

anonymous (*) (2003-07-02 12:30:45.373099):

> Вопрос не о фичах а о внутренней структуре и из нее растущих последствий Почитай как устроен внутри постгрес и как Innodb и тебе сразу хорошо станет.

Читал. И то, и другое --- версионники. В чём *принципиальная* разница-то?

> Тривиальный пример - попробуй залочить этак 100.000.000 строк в табличке на Postgres, а потом попробуй поменять не залоченые...

"тривиальный"? :)

То есть я сначала делаю SELECT ... FOR UPDATE на куче строк, а потом UPDATE по совсем другим строкам? :) Чё-то такой "тривиальной" последовательности действий пока ни разу не требовалось. :)

Припципиальная разница в использумых алгоритмах распределения. Управления памятью блокрировках итд.

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

>А если нет то похоже MySQL почти никому не нужен будет. >Ну напрягусь я - один раз перенесу таблицы из MySQL куда >нибудь еще. А то возиться потом - тут PHP c MySQL работает >там не работает да пошел этот MySQL в жопу, буду пользоваться >тем что везде без проблем работает. >Troll (*) (2003-07-01 16:04:42.788651)

Отучаемся говорить за всех, с Perl MySQL используется не менее активно чем с php, а вот php поплохеть вполне может

> Хм. А какие это у вас запросы и где? А то 40000 запросов в минуту = ~700 запросов в секунду, а ведь наверное ещё и пики бывают? ;)

Запросы несложные. Много селектов, много инсертов. Приложения
обычные - интернет-магазины, информационные базы. 40тыс/сек -
это и есть на пике. Постгрес ложится на такой нагрузке.
Сервера не слабые, но апгрейдить их до бесконечности нельзя,
так как нужно вписаться в 2U. Mysql-4.0.х идеально подходит для
такой ситуации. Ближайшие конкуренты мягко говоря очень далеко...

> Постгрес ложится на такой нагрузке.
> ...так как нужно вписаться в 2U

подозреваю, что постгреса Вы грузили заточенными под мускул запросами - мы это уже проходили, видел как программер, имевший опыт с мускулом, легко загнал в клинч постгреса. кстати,и наоборт тоже легко можно.;-)
между тем, у постгреса (как и у мускула) есть множество тонких настроек, сильно влияющих на производительность.
про 2U: мне всегда казалось что для СУБД самое главное - это быстрые диски и много ОЗУ, в Ваши 2U легко влазит удовлетворяющий этим условиям IBM x335 или Intel.

<цитата> на эту тему есть хорошая статья Тима Пердью - сравнение MySQL vs. Pg. ссылку не помню. по гуглю легко ищется, на пхпбилдере что-ли. </цитата>

хехехе. Вечно живая статья. Вы ее дату то видели? Кстати, с mysql.com:

We asked Tim if we could get access to his data so that we could repeat the benchmark and if he could check the MySQL version on the machine to find out what was wrong and he promised to come back to us about this. He has not done that yet.

Вы верите в честное сравнение после этого?

Это всего лишь бета. Готов поспорить на щелбан с любым, что к релизу - mysql останется в php где он и был.