Отчет: СУБД с открытым исходным кодом становятся мейнстримом

Согласен насчет PgSQL.
MySQL - вещь попсовая, и как уже много раз тут говорилось, пригодна только для создания хомпейджов васи пупкина.

М.

и для хостинга которой годится лишь твоя тезка-ось

Кстати, только что выложили PostgreSQL 7.4.2 с чем нас всех и поздравляю. Новость на LOR я запостил уже давно, но модераторы спят как обычно.

Качать с ftp://ftp.postgresql.org/pub/binary/v7.4.2/

МОДЕРАТОРЫ МЛЯ - НЕ СПАТЬ!!!

Щас нужный пост прибьют по моему любимому пункту "4.4 - Обсуждение действий модераторов." Лучше добавьте "4.4.1 - Обсуждение бездействий модераторов."

:))))))))))

2OpenStorm

Спасибо!

> MySQL - вещь попсовая, и как уже много раз тут говорилось, пригодна только для создания хомпейджов васи пупкина.

А нахуя Пупкину БД?! MySQL не попсовая она быстрая.

Люди! Я не пойму. Вас что плющит? Вы говорите так, как будто каждая вторая фирма/организация которой нужна база данных - это монстры с 1000000 клиентами. Вы не забывайте, что основная масса пользоателей - это маленькие хостеры и провайдеры на клентов 100. А им к черту сдался ваш Оракл и дб2. Они лучше будут использовать MySQL и др. почти на халяву.

> MySQL - вещь попсовая, и как уже много раз тут говорилось, пригодна только для создания хомпейджов васи пупкина.

Транзакции есть, репликация есть, подзапросы есть. (Я про 4.1)

Что, вам так нужны триггеры и хранимые процедуры, чтобы делать что-то сложнее домашних страниц?

ветку 5.0 никто не пробовал?

HellAngel - посасывает в каком смысле? Ну дык мускуль тоже посасывает у постгреса кое-где.
Vond - угу, есть и такие места где нужны все эти прелести. В конторе сначала был биллинг на MySQL (т.к. предыдущий админ дальше него не знал). При этом кое-какие временные записи "терялись" из-за отсутствия транзакций. + была проблемка когда питание дергали - некоторые таблицы приходилось repair'ить, чтобы биллинг работал дальше. После переезда на постгрес, обе проблемы отпали.

Переезжать на альфы от mysql не очень тянет... Постгрес уже давно вылизывают, и работает он отлично, там где надо.

> Транзакции есть, репликация есть, подзапросы есть. (Я про 4.1)

> Что, вам так нужны триггеры и хранимые процедуры, чтобы делать что-то сложнее домашних страниц?

Честно. Хотя бы O_CLOEXEC на клиентской стороне для сокета. Да и код у них такой, что закачаешься. Грязный хак на грязном хаке. Хотя, для персонально-домашней страницы покатит. Тут ведь важно помнить основной закон органической химии: если к 2 кг говна добавить 2 кг повидла, то получится 4 кг говна. Так что, даешь для убогих поделок убогую СУБД с перпендикулярным ко всем интерфейсом. Postgres куда как приятней этой поделки во всех отношениях.

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

:) По моему мнению, если база/таблицы валятся, то это проблема БД, а не писавшего.

М.

по моему, если таблицы валятся от внезапного выключения питания, то это не проблемы бд, а проблемы администрирования системы (ups need).

>>И будет у нас две версии языка SQL - та, которая будет стандартная, и та, каторая будет работать у каждого юзера (mssql).

Нету никакого стандартного SQL-ла. Фикция все это. А если и есть то только до определенного уровня. С помощью SELECT * FROM mytable много не напишеш.
Читайте ТКайта "Оракл для профессионалов". Это у него нормально обоснованно.
И потом. Процедурное расширение SQL вовсе не обязано быть переносимым. Вот и полнятся форумы "как мне перенести такуюто фичу из МССКУЛа в Оракл?"

> по моему, если таблицы валятся от внезапного выключения питания, то это не проблемы бд, а проблемы администрирования системы (ups need).

мда... про WAL и транзакции вам еще читать и читать...

транзакции не всегда являются необходимым свойством бд (1. множество вещей можно сделать атомарными операциями. 2. некоторую /не все случаи конечно/ степень проверки по ссылочной целостности можно возложить на логику приложения). а вот физическая целостность данных - не дело базы.
или (по аналогии) вы считаете надежность ФС более важной, чем надежность диска? по мне так это разные уровни

>по моему, если таблицы валятся от внезапного выключения питания, то это не проблемы бд, а проблемы администрирования системы

отказ питания не единственная причина падения и не всегда УПС поможет база должна защищать от таких сбоев и точка. Если БД не умеет транзакции то это не БД а поделие уж простите. А кто этого не понимает марш читать теорию.

> по моему, если таблицы валятся от внезапного выключения питания, то это не проблемы бд, а проблемы администрирования системы (ups need).

Я дёргал питание на тестовом серваке с ораклом. EXT3 выжила. А оракул и подавно.

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

>1. множество вещей можно сделать атомарными операциями

Молодой человек что вы называете атомарными операциями? Транзакции как раз и призваны сделать несколько логически связанных операций над БД атомарными бишь неделимыми, либо они выполняются все либо ничего, это не только полезное качество нормальной БД но и необходимое. Ибо любая грпповая операция над базой (а SQL это язык для обработки групп данных) при отсутствии транзакций становится не безопасной. И сторого говоря даже нормальный телефонный справочник бех этого не напишешь.

>некоторую /не все случаи конечно/ степень проверки по ссылочной целостности можно возложить на логику приложения

можно конечно. только это не есть хорошая идея. Только один пример при смене морды приложения работующего с БД скажем с текстовой на GUI или Web вам придётся снова и снова повторять логику приложения, отлаживать итд итд это гимор да и опасно для данных. Так что если ваше приложение сложнее тел. справочника то крайне не рекомендовано делать проверку ссылочной целостности в приложении. Ну не говоря уже о том что существуют способы внести изменения в БД и в обход вашего прекрасного приложения.

>а вот физическая целостность данных - не дело базы

механизм транзакций и внешних ключей в основном направлен на обеспечение логической не противоречивости данных.

вооющем вы ещё слишком молоды и слишком мало знаете/понимаете в БД уж простите но это так. Первый же серьёзный проект, ксли он у вас конечно будет надеюсь откроет вам глаза

у тебя есть статистические данные например по 100 внезапным сбоям по питанию и проблемам, которые при этом возникают у ФС, мускула, оракла и др? нет? тогда нечего выдавать единичный результат за правило. ФС вообще живучи стали. за последние 3 года пользования ext3 у меня набралось в сумме несколько десятков сбоев эл. сети (это в нескольких местах, в том числе неблагоприятных) и несколько десятков моих ресетов. итог: один (или два, точно не помню за давностью того случая) раз ext3 немного рассыпалась. fsck починил без каких-то катастрофических потерь данных. но на работающих базах такой статистики у меня нет (и слава богу)))

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

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

а по поводу интерфейса - вы предпочитаете двухуровневую модель видимо, раз для каждого интерфейса приходится менять логику? а я трех. прямо сейчас (тот проект, который пишу) логика приложения генерирует xml. а уж с помощью чего я его в html буду преобразовывать ее не касается. проверял специально в начале разработки: и мозилла и sablotron нормально все пережевывали с помощью одного и того же xslt

в догонку: я знаю что такое внешний ключ, триггер, транзакция и для чего они нужны. так что не надо мне говорить rtfm :))

>>механизм транзакций и внешних ключей в основном направлен на обеспечение логической не противоречивости данных >разве одно другому противоречит?

безусловно не противоречит, и механизмы ФС очень важны, хотя если вспомнить Оракловские рав девайсы то видно что можно жить и без ФС.

>да и сейчас есть небольшой проект чуть сложнее телефонного справочника

я же не сказал что нет задач в которых нельзя обойтись без транзакций. Безусловно такие задачи существуют, но если вы серьёзно занимаетесь базами данных то таких задач не будет а если это "не мое поле деятельности" тогда вообщем то всё равно на чём вы пишете. А то что разрабатывать нужно по разному это вы верно подметили:)

>а по поводу интерфейса - вы предпочитаете двухуровневую модель видимо, раз для каждого интерфейса приходится менять логику? а я трех. прямо сейчас (тот проект, который пишу) логика приложения генерирует xml. а уж с помощью чего я его в html буду преобразовывать ее не касается

знаете для меня трёхуровневая модель всегда была немного большем чем генерация xml и перегонка его в html:) Еслиб интерфейсы ограничивались только браузером это былабы сказка:) на самом деле ведь приходится ещё писать и толстых клиентов, для некоторых задач это лучший вариант. да и много чего ещё. У меня сейчас в проекте порядка 100 таблиц связанных а вьюхи ещё, и это только начало:) Так вот если вы хотите чтоб я повесился скажите мне что моя БД перестала поддерживать транзакции, ссылочную целостность и триггера уверяю я тут же пойду мылить верёвку;) А если серьёзно я скорее обойдусь без сервера приложений чем без полноценной БД.

> у тебя есть статистические данные например по 100 внезапным сбоям по питанию

Нет у меня такой статистики. Т.е. вообще. И говорим мы не о файловых системах. Попробуй, не вырубая питания, скриптом угрохать все процессы оракла во время длительной транзакции. А потом попробуй тоже издевательство с мускулем. (с постгресом дела не имел). Почувствуй разницу. Оракл живет не только на ФС. Он сам себе может быть ФС.

Примеры таких задач. Для них простых текстовых или индексных файлов не хватит?

http://www.sanchez-gtm.com/

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

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

все понятно. т.е. у меня и изначально было подозрение что мы несколько о разном :)) у меня на пару порядков попроще задачи и толстому клиенту нечего делать (впрочем, на некоторых операциях я бы с удовольствием разгрузил сервер, но как подумаешь о зоопарке ОС, установленных у нас macos9/macosx/winnt/2k/xp(?)/*nix - сразу все желание пропадает. лучше я с кешированиями, оптимизациями и udf повожусь немного).

товарищу со 100Г базами: вот когда (скорее если) у меня будут такие объемы (в других проектах), тогда я скорее всего поменяю свое мнение. не думаю что правило 20/80 перестало действовать и в этой области. 80% задач малы. правда стоят они 20% от общей массы денег, крутящихся в этой области :))

Все-таки приведи пример задачи. Это задача, где клиентом базы является одна и только одна программа, и при этом она никогда не пишет и не читает одновременно, или это задача, где главное --- показать случайным образом какие-нибудь данные?

Зачем тогда RDBMS? Пользуй либу из раздела dbm, тем более, есть из чего выбрать.

> оракл .... восстановит практически все (не со 100% вероятностью)

оракл восстановит все со 100% вероятностью

Поэтому его и ПОКУПАЮТ. (Иногда и России :)

100% вероятности нет и у оракла, мудило

> 100% вероятности нет и у оракла, мудило

Сможете смоделировать реальный отказ техники при котором невозможно восстановить состояние на момент отказа?

Как говорят в Ваших кругах: "Чем ответите за базар?"