> SQLite позиционируется как простая база для вебсайтов, оптимизированная под частое чтение и редкую запись

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

> ROTFL... я аж поперхнулся... однако =)

Могу лишь высказать своё соболезнование и виртуально постучать по спинке ;)

> Ты вообще видел что такое sqlite?

Работаю с ним. А что хотел-то?

> Может еще скажешь, это та же целевая аудитория, что и у Oracke? =)

Не знаю. А что такое Oracke? ;)

Один говорит "простая" и "для вебсайтов", другой - "просто либа" и для
хранения музыки ;) А слабо вместо гаданий прочитать документацию? ;)

> А слабо вместо гаданий прочитать документацию? ;)

Не слабо, но в доках не написано, для чего она =)

Впрочем, что 90% мелкосайтов, которые сейчас крутятся на мускуле, могли бы спокойно переехать на sqlite - не спорю.

> Не слабо, но в доках не написано, для чего она =)

Дык откуда дровишки тогда? Не надо выдавать своё воображение за твёрдую
истину.

> Впрочем, что 90% мелкосайтов, которые сейчас крутятся на мускуле, могли бы спокойно переехать на sqlite

Опять Остапа понесло ;( Ну, да бог с тобой... Точно так же можно
сказать, что 90% мелкосайтов, которые сейчас крутятся на postgres,
могли бы спокойно переехать на mysql ;) Шутки-шутками, но, к примеру,
мелкосайт LOR точно мог бы.

> Дык откуда дровишки тогда? Не надо выдавать своё воображение за твёрдую истину.

Ну-ка покажи где я выдавал за "твердую истину"? Или вам после каждого слова "имхо" писать, чтоб если что не обиделись? Как дети, ей-богу (имхо) ;)

> Опять Остапа понесло ;( Ну, да бог с тобой... Точно так же можно сказать, что 90% мелкосайтов, которые сейчас крутятся на postgres, могли бы спокойно переехать на mysql ;)

Поскольку сайтов, крутящихся под постгресом, я особо не наблюдал (явно - а так хто их знает что они там крутят), то ничего не могу сказать по этому поводу =) Но могу поверить. Так что, скажешь, я все-таки был неправ? Ладно, 90% - это с потолка, понятно, но определенно больше половины... =)

А чего следующее предложение не запостил ? Видишь только то, что придется?

But we have to consider too, that mysql in its default config (myisam tables) doesn't recognice foreign keys and does not check this restriction, so it is normal to see that mysql is faster loading data.

> Ага, особенно, если не хотел их видеть ;) Взгляни: http://people.ac.upc.es/zgomez/tpch-results.html

Сказочный тест. :)

> So the two DBMS had exactly the same database definition with exactly the same indexes for each table.

но при этом

> But we have to consider too, that mysql in its default config (myisam tables) doesn't recognice foreign keys and does not check this restriction, so it is normal to see that mysql is faster loading data.

про настройку, конечно, ни слова, но чтобы PostgreSQL на таком железе загружал 1Гб 2,5 дня --- это *очень* постараться надо.

и в комментариях перл (http://people.ac.upc.es/zgomez/pedro.html):

> We need to take a closer look at the "strange" cases: Q3 and Q5 execute better on pgsql.

то есть типа недоработка: PostgreSQL быстрее работать не должен! Ну что ж, надеюсь в следующей версии они это исправят.

> Шутки-шутками, но, к примеру, мелкосайт LOR точно мог бы.

И чуть было не переехал, но я как-то проконсультировал его владельцев на предмет нормальной настройки PostgreSQL.

И несчастным мысклеводам до сих пор прходится доказывать, как крута их база на сайте, который работает на Postgres'е.

Абыдна, да?

на калькуляторе пускать не пробовал?

мысклеводы - вперёд на:
http://www.opennet.ru/opennews/art.shtml?num=4056
когда в муццкуле всё это будет хотя бы в todo листе на ближайший год ? тогда чесслово, буду смотреть на муццкуль.
а сейчас муццкуль ну никак использовать не могу.
ибо при более-менее сложной логике проекта, муццкуль, к сожалению, посасывает "нипадецки". как в плане производительности, так и по отсутсвию фич.

> И чуть было не переехал, но я как-то проконсультировал его владельцев

Ах, так вот откуда трава!! А я то думал... А чего ты его заодно на счёт
жабы не проконсультировал? ;)

> Абыдна, да?

За что абыдна? За то, что до твоей настройки скрость была ниже в 20 раз
от оптимальной, а после твоих советов стала ниже только в десять раз?
Нет, за это можно только порадоваться! ;)

Блин, ну видал я упёртых пионеров, но таких зацикленных на одном
продукте надо ещё поискать... Уж казалось бы, чего спорить зря?
LOR - пионерский сайт, ничего сложного в нём нет, никакой бизнес-логики,
тривиальный blog. Мускль на него ложится идеально. Скорость - минимум
в три раза выше самого оттьюниного постгреса. Так нет, всё равно надо
рвать глотку и орать, как крут и незаменим постгрес. Фи.

> Сказочный тест. :)

Проделай свой и выстави на всеобщее обозрение. Вдруг мы тебе поверим? ;)

Re[7]: MySQL 4.1 теперь beta

> VIEWS в 5.0 скорее всего будут.

А хранимые функции когда на скриптовых языках будут? В 7.0? Заколебали! Тоже мне СУБД... Маркетинговая политика мало чем отличается от строительства коммунизьма. Того гляди, перестройку начнут, а там и до 15-ти форков рукой подать...

> Ну-ка покажи где я выдавал за "твердую истину"? Или вам после каждого слова "имхо" писать

Да, в том контексте - должен обязательно. Слишком короткое и прямое
утверждение. Откуда взял? Где источник? Источник - имхо ;)

> Поскольку сайтов, крутящихся под постгресом, я особо не наблюдал

Скажи, чего вообще в своей жизни ты наблюдал? ;) Ладно, салют пионерии.
Интересное поколение подрастает ;)

> когда в муццкуле всё это будет хотя бы в todo листе
"запланирован на начало сентября 2004 года"

Чушь, не сделают к сентябрю.

> За что абыдна? За то, что до твоей настройки скрость была ниже в 20 раз от оптимальной, а после твоих советов стала ниже только в десять раз?

> LOR - пионерский сайт, ничего сложного в нём нет, никакой бизнес-логики, тривиальный blog. Мускль на него ложится идеально.

О чём и речь --- зелен виноград. :-D

Смотреть приятно, как ты, бедняжка, слюной исходишь. :-D

> Чушь, не сделают к сентябрю.

Ну уж к концу текущего года точно сделают. А вот мыскль 5.0 мы будем пускать уже на Longhorn'е (если конечно ООО "мыскль" до того не обанкротится).

sad_spirit, вот вам по пунктам о том что и когда будет в MySQL:

- Tablespaces (огромные базы могут быть распределены на нескольких дисковых разделах),

В 4.1 innodb может иметь по tablespace на табличку. MyISAM всегда мог быть на разных дисках (читать про симлинки) Согласен, это не схема m:n, но это решение, которое люди могут использовать уже сейчас.

- Выпуск версии для Windows;

Есть давно.

- Встроенный pg_autovacuum;

Проблема локальна для постгрес.

- PITR (Point In TimeRecovery) Полное восстановления данных после краха используя бэкап и "write-ahead" лог.

Есть. В 4.1 опции по этому поводу добавили, чтобы лог накатывать к определённой точке.

- Поддержка инкрементальных бэкапов;

Нет, но есть ibbackup (да, платный, платный).

- Лимиты на число коннектов на пользователя/базу;

Давно есть.

- pg_upgrade для обновления версий PostreSQL, при изменении бинарного формата файлов базы, без использования dump/restore;

Проблема локальна для Postgres.

- large objects: vacuum как /contrib/vacuumlo, автоудаление при удалении записи-владельца, доп. проверки направленные на безопасность;

Проблема локальна для Postgres.

- Локализация: разная локаль для разных столбцов, одновременное использование нескольких charset'ов,

Есть полностью в соответствии со стандартом в 4.1

Т. е. общий вывод какой - существенная часть того что делает postgres в MySQL уже сделано.

> ИМХО пока теория не за ООБ, а SQL на то и SQL
Может быть все-таки тут что-то не так с терминологией? А то по ушам режет...

>Сервер нагруженный, около 50 тыс. mysql-запросов в час, загрузка 2x
>Xeon 1800 редко ниже 5% падает :)
Приложенние комерческое? Лицензию купить не забыли?

>Т. е. общий вывод какой - существенная часть того что делает postgres
>в MySQL уже сделано.
Работу с курсорами сделали?

> MyISAM всегда мог быть на разных дисках (читать про симлинки) Согласен, это не схема m:n, но это решение, которое люди могут использовать уже сейчас.

Симлинки в PostgreSQL тоже щас можно использовать. Но мы ведь тут говорим не о костылях, а о решениях, ага?

> Нет, но есть ibbackup (да, платный, платный).

давно есть pg_dump (бесплатный, бесплатный). Да и инкрементальный бэкап получится попродвинутей, чем то, что описано в мануале MySQL.

а если начать вспоминать о платных решениях, то есть:

PostgreSQL для Windows, причём threaded: http://www.sraapowergres.com/

Кластер: http://www.linuxlabs.com/clusgres.html

и т.д.

вообще пока разговаривать на тему нововведений рано, вот дождёмся беты PostgreSQL 7.5, и вернёмся к вопросу.

2eXOR: курсоры в 5.0 должны быть. 2sad_spirit: не сравнивайте pg_dump и ibbackup это принц. разные решения

Кстати, вопрос знатокам (маюсь уж недели полторы):

Есть две таблицы:

Компания
company_id
address
...

и

Филиалы
filial_id
company_id
address
...

В них, понятное дело, живут "компании", которые имеют разный address и их филиалы, по каждому из которых хранится company_id и опять же address. Вопрос -- как выбрать все филиалы одной компании, которые находятся в N указаных городов? Конструкция вида

SELECT * FROM Компания, Филиалы WHERE Компания.company_id=Филиалы.company_id AND address="Питер" AND address="Москва"

естественным образом не канает.

Попытки извращаться с разнообразными подзапросами, скобками, логикой не спасают... Вариант OR тоже не катит (нужны не все, где "или там или там", а "и там и там". Есть мысль, что на SQL такого свойства штука вообще не ложится естественно.

Мне особенно нравится "полностью реализован SQL 92" - это с одним типом строка то ?

может я что-то не понимаю? или все-таки ты сам не понимаешь чего хочешь и/или не можешь выразить это словами?

> Есть мысль, что на SQL такого свойства штука вообще не ложится
гы! :) это самый рулезный пример.
брать Грубера, читать про join и having.
работать будет и в мускуле и свежих постгресах.
что-то типа select * from co c, fi f, fi d where c.c_id=f.c_id and f.c_id=d.c_id and f.address='Москва' and d.address='Питер';

> вообще пока разговаривать на тему нововведений рано, вот дождёмся беты PostgreSQL 7.5, и вернёмся к вопросу.

Ну, дык а чего тогда ротик раскрываешь впустую?
"Дождёмся", "вот выйдет"... Как выйдет, тогда заходи, гостем будешь.
Где вы говорите, товарисч, учились? В заборостроительном?

> то с одним типом строка то ?

Ты спутал с внутренним представлением. Оно тебя волновать не должно.

> как выбрать все филиалы одной компании, которые находятся в N указаных городов?

Вопрос сформулирован очень плохо, но понять можно теоретически...

Вариант ответа:

$cities = array("Питер", "Москва");
$num = count($cities);
$where_cities = join(",", $cities);

SELECT count(*) as cnt, K.company_id as id FROM Компания K LEFT JOIN
Филиалы F ON (K.company_id=F.company_id) WHERE F.address IN
($where_cities) GROUP BY id HAVING cnt = $num;

(Код не протестирован)