Сравнение Open Source СУБД

Поражён обьективностью=(

Для Postgresql отсутствует поддержка Linux x86-32, отговорку я не понял:
The most important platforms supported by the DBMS are shown in the following table. If you are looking for a particular operating system / architecture which is missing, then please make sure that
you visit the provided resources.

а подскажите мне пионеру в постгрессе можно выделять права на уровне колонок? или только на всю таблицу?

Бегло (очень) посмотрел: а почему там не написано ничего про тригеры и хранимые процедуры?

Как это отсутствует поддержка лину-х86 ? У меня под федорой 8.0.2 работает и не заикается, собран из сорцов без всяких хаков.

Потому что известно_где их нет :) Это как сравнения известно_кого с Oracle - получается что последний медленнее для веб-сайтов с сотней страниц и десятком хостов в день :)

майкрософт наконец опубликовало tpc-c тест юкона, как и ожидплось майкрософт сосет :)

http://tpc.org/tpcc/results/tpcc_result_detail.asp?id=105060604

Как это не написано? Страница 30.

>Как это не написано? Страница 30.

Ой, сорри. Чего-то слишком бегло. Ща почитаем :)

Хорошее сравнение, молодцы. Из предложений - включить в обзор сравнение GIS реализаций для СУБД Например, postgis для postgresql. Для остальных есть ли похожие проекты - не знаю.

>майкрософт наконец опубликовало tpc-c тест юкона, как и ожидплось майкрософт сосет :)

Не Microsoft, а HP. И не проиграл, а выиграл.

chto meshaet vam sozdat' VIEW, hotja by i dlja odnoj kolonki? mozhno povozitsja s RULE.

гыгыгы. мускуль как всегда отсосал по полной

А посоветуйте новичку какая из этих СУБД летше? не для чего-то конкретно а в обшем.

А посоветуйте новичку какая из этих СУБД лутше? не для чего-то конкретно а в обшем.

postgresql конечно. И вслучае чего без труда можно перейти на Oracle.

Ну блин, и совем недорого :))

Очень легко и быстро осваиваиваемая, почти со всеми возможностями современных СУБД, мало жрёт и весит - Firebird. Клон Interbase от Borland'а, но Firebird IMHO лучше, к тому же бесплатный :). Тока под линь гуишных прог для работы с ней наверняка нет. Но всё в принципе лёгко делается скриптами.

http://www.ibase.ru/ - тут были линки на гуй для Firebird. Прадва не знаю есть ли для 1.5. Последний раз на эту БД смотре при версии 1.0.

А кто из многоуважаемых может высказаться в сторону самой быстрой БД (даже не бесплатной)? На малых базах и небольших запросах практически все работают достаточно шустро (за исключением монстров), но стоит перейти за 7-ми значное кол-во записей с 10+ полей и сделать нормальный запрос, тормоза просматриваются везде.

К примеру нужно сделать update в котором where = на 2-3 поля, like на пару полей и between на пару полей (в результате выборка где-то на 500 000 - 1 500 000 записей). А в таблице около 80 000 000 записей.

Кто с таким сможет справиться за 3-5 секунд? Это реально вообще?

Общался с сотрудниками Cache - вроде били себя пяткой в грудь... Но протестировать у меня так руки и не дошли.

Пробовал MySQL, PostgreSQL, Firebird(1.0), SQLite, Sybase, Oracle. Результат меня удивил:

MySQL, PostgreSQL, Firebird - трудились почти одинаково минут 40 - час.

SQLite - раза в 1,5 подольше наверное.

Sybase - спустя несколько ч_а_с_о_в (порядка 6 часов если я правильно помню) выдал ошибку о том что ему не хватает места под transaction backup и бросил это дело.

Оракул я вырубил после долгого ожидания результата (решил что будет не быстрее sybase)

По сей день так и не нашел ничего сверхестественного и в то же время доступного (недоступное знаю что вроде есть) для обработки больших объемов данных, пригодного для WWW.

Разработчику оторвать все, что торчит. Сразу после постановщика задачи.

За других не скажу, но за оракл -- смешно. Шутку понял. Рекомендую начать думать, может тогда чего получится.

Результат выборки 1 000 000 записей примерно по 8 байт поле и 10 полей в таблице будет составлять около 80 мегабайт. Т.е. сервер должен читать данные с диска и выдавать их клиенту со скоростью 25-30 мегабайт в секунду. (Это чисто прикидка безотносительно к тому Oracle это или MySQL) Конечно такое возможно, но на не самых базовых машинах. И это о выдаче результата, а ведь нужно время на сканирование таблицы...

И что - действительно есть потребность в получении 1000000 записей клиентом ?

> Результат выборки 1 000 000 записей

А там не выборка, там обновление! Чтение-изменение-запись. Это не считая транзакции. "Душераздирающее зрелище". Да еще и кривейшие индексы, скорее всего.

Хочется автора спросить: а нахрена это ему? Что-то я с огромным трудом представляю себе рутинную задачу обновления в один прием миллиона записей. Да еще и для "WWW".

Нда - про update я и не углядел. Аффтару - в начальную школу в Бобруйск поучиться...

Коротко:

Есть товар с 10 параметрами, каждый параметр имеет по 10-200 значений.

Для каждого сочетания нужно сгенерить SKU по определенной формуле зависящей от значений параметров.

Другая задача - добавляется товар в базу. При этом указываются крайние значения параметров и шаг, либо просто перечисляются возможные значения (если нет возможности посчитать их). При этом кол-во сочетаний так же может быть более миллиона. Главное что все сочетания нужны для инвентаризации (т.е. просто список возможных знечений для каждого из параметров - не подходит).

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

Это кому интересно, хотя мне кажется это уже другая тема.

> И что - действительно есть потребность в получении 1000000 записей клиентом ?

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

>http://www.ibase.ru/ - тут были линки на гуй для Firebird. Прадва не знаю есть ли для 1.5. Последний раз на эту БД смотре при версии 1.0.

Наверное имелся ввиду IbExpert? Он тока под Вынь. :( А тулза классная, правда её огромные возможности являются причиной её нехилой тормознутости. А FB 1.5 рулит. Я на него перекинулся под Вынью с Interbase'а по причине того, что его Classic вариант в отличии от суперсервера (а борланд классик уже не лепит) на каждое клиентское подключение создаёт свой отдельный процесс и клиенты обслуживаются "параллельно" и равноправно. А в классик варианте один громоздкий или бездарный запрос от одного клиента способен привести к тому, что все остальные клиенты будут "курить" в сторонке ожидая пока полностью не отработает "тормоз". Честно говоря так и не понял, а нах... тогда нужен Superserver если он такой тупой?

Можно вот на это посмотреть: http://www.minq.se/products/dbvis/index.html

Значения параметров можно вынести в отдельную таблицу/таблицы, а состоящий из комбинаций результат получать через join (можно и вьюшку сделать). Тогда при добавлении товара или изменении списка параметров не нужно заносить в базу все возможные комбинации и работы будет на пару порядков меньше.

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

Кстате - да! PostgreSQL вплоть до 7.{чего то} имел дефолтные настройки подходяшие для машин с 64~128 MB RAM. После устраивания "барских щедрот" :) в конфигах сразу хорошело ....

2 breaK (*) (08.06.2005 15:45:55)

Этот вариант спасает в случае если:

1) нету инвентаризаии товаров... (в противном случае как можно узнать кол-во для каждого сочетания параметров)

2) не нужен собственный SKU для каждого сочетания (т.е. свой собственный код для каждого сочетания параметров).

Более того. Этот вариант был первоначальным и летал "шо немой" на любой БД. Но позволял покупать отсутствующие товары или же просто не существующие (не все сочетания могут существовать)...

Поправьте если я не прав.

Думать над чужими задачами влом ;) Но так на первый взгляд может быть тебе действительно Cache' поможет.
Но только надо приготовиться, что эта БД _совсем_ другая по сравнению с реляционными. Там данные лежат в деревьях. А объекты, реляционные таблицы и т.д. - это всё равно на деревья сверху натянуто, как интерфейс.
Внутренний язык ('M') такой закорючный, что поначалу кажется сущим кошмаром, после него perl - это так, халява ;)

2 Dimentiy (*) (08.06.2005 23:04:32)

Спасибо за предупреждения... Хотя теоретически я это знаю. А про думанье над чужими задачами - это дело конечно лишнее... :) Я выдал эти данные для того что бы дать представление о задаче, под которую хотел бы найти БД. Только и всего.