Эхма, ну че он такой неказистый?

Эхма, ну че он такой неказистый? Налеплено всего до кучи, не СУБД, а карикатура сама на себя :(
Напридумывали таблиц разных типов, транзакции вообще где-то сбоку...
Короче жудик какой-то

Жудко смотрится после Oracle и PostgreSQL ;)

Народ вот вопросец по делу весь билинг крутится на 3 ветке, есть смысл переходить на 4 ? и как там с совместимостью будет ?

creat

2creat: есть смысл переходить на postgreSQL. Билинг - слишком серьёзная система, чтобы доверить её субд без транзакций и контроля целостности.

А какая операция в биллинге жизненно требует транзакций и почему контроль целостности нелзя возложить на сервер приложений?

Все это уже давно есть в mysql 4.x Так что живущим во времени конца девяностых, просьба свалить нах... а не пихать в каждую ветку о мускуле, свой постгрес.

2Eugene_Korobko: не чуди о том, чего не знаешь, любишь постгрес - рад за тебя, но и в мускуле можно сделать надежную систему, надо только уметь.

2anonymous: да можно даже на FoxPro под дос сделать надёжную систему. Но 1) отсутствие контроля целостности в MySQL - это факт 2) отсутствие транзакций - это факт Я люблю SQL-92. Люблю делать exec("begin transaction"); try { ... exec("commit"); } catch(...) { exec("rollback"); }

2dsa: транзакций требует любая операция, состоящая более чем из одного запроса. а возложить контроль целостности на бизнес-логику - это неверное решение, т.к. у кажного уровня - своя задача. 2anonimous: посмотри здесь: http://www.mysql.com/doc/en/TODO_MySQL_5.1.html Только в пятой версии планируется сделать: ... FOREIGN KEY support for all table types. Column-level constraints. ...

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

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

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

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

не всегда, во-первых (что мешает в catch поместить cleanup code?) - жили же в клиппере, и неплохо жили. тем более при единственном пользователе, модифицируещем данные), а во-вторых, биллинг... биллинг... Хм. В правильном биллинге, ничего кроме insert'ов делаться не должно :). А вот insert'ы должны делаться быстро. Без затрат на транзакции.

>возложить контроль целостности на бизнес-логику - это неверное решение

на этот счёт существует более одного мнения. Например - условие целостности -- значение поля А должно быть всегда равно сумме значения полей Б и В или там дата должна быть обязательно рабочим днём. Все равно его придётся запихивать в приложение. Какой смысл - "размазывать" все проверки и на уровень приложения и на уровень СУБД?

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

Транзакции есть и в 3.23.*, уже года два как. Почитайте, что такое InnoDB (www.innodb.com)

Да я и не говорю, что MySQL -гавно. Для форумов, гостевых книг, вообще, некритичных сайтов - самое то. Только вот там, где дело касается денег (билинг, финансы и пр.) нужно использовать что-то по-серьёзнее. Да, делали и на клиппере. Но если есть инструмент, который сам управляет такими вещами? Сейчас же никто (крома динозавров) на клиппере не пишет! Потому что есть более подходящие средства. Про innoDB я знаю. Но это не часть субд, а внешняя пристройка. Что вообще как-то странно.

Кто нибудь rpm пакет собирал? Вот прикол! Скачал source rpm. Собирается нормально без ошибок. Запускаю и вываливается в лог без конкретных указаний, типа отправте разработчику. Ну думаю дай скомпилю на другом дистрибутиве. Тоже самое. проверял на RedHat-9 и RedHat-7.2. что это - бага в srpms ?? помню что в версии 4.0.14 все запускалось отлично.

P.S. Я вот использую FoxPro под дос. Как только заходит о нём речь, сразу толпа налетает: переходи на SQL! Достали! Что такого в этом SQL? Подумаешь, транзакции, целостность... У меня программа сама всем этим управляет, и нечего, всё работает.

Eugene_Korobko ламер это факт.

транзакции в mysql еще в 3-й прикрутили. мне вот оракл нравится и дети типа тебя пишущие begin transaction с sql-92 в фокпро вызывают умиление.

Desperado

хочу заметить только что выражение
"Билинг - слишком серьёзная система"
неверно
биллинг это самая несерьёзная задача которую я только видел

>Про innoDB я знаю. Но это не часть субд, а внешняя пристройка. Что >вообще как-то странно.

ничего странного imho. opensource и все такое.

и это именно часть субд. mysql-3.23.xx.tgz вытягиваешь - и оно там.
компилируешь и пользуешься.

ты чего такой упертый? оно там есть и мы им пользуемся.
посмотри http://www.innodb.com/userstories.html

:)

Уважаемый Eugene_Korobko, утверждения про отсутствие контроля
целостности и отсутствие транзакций в MySQL, - это, скорее, - факт
Вашего *невежества*! В MySQL есть поддрежка всех четырёх уровней
изоляции транзакций, определённых стандартом SQL92.
Если Вы что-либо утверждаете, то будьте любезны это аргументировать
с помощью фактов, а не размахов руками.

--
Andy

Eugene_Korobko

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

у нормального хирурга разные инструменты имеются для разных целей

и под слакой пойдет?

обязательно :-)

> А какая операция в биллинге жизненно требует транзакций и почему контроль целостности нелзя возложить на сервер приложений?

НЕЛЗЯ. Почему - почитайте умные книжки. А пока вы в очередной раз сморозили глупость.

> НЕЛЗЯ. Почему - почитайте умные книжки.

Читали. Потому и спрашивают про конкретику. Общими фразами все умеют говорить. Покажи, где конкретно понадобилась трнзакции,
а мы расскажем, где непорядок в твоей голове, и в каком месте
умные книжки дурно повлияли на твой неокрепший мозг.

http://www.mysql.com/doc/en/ANSI_diff_Transactions.html

Если ты не панимаш про 4 типа изоляций и зачем они нужны, то тебя надо ссаными тряпками от сервера гнать. И засунь себе "сервер приложений" куда подальше.

Зачем нужны транзакции

http://rdbms.narod.ru/faq/#R-SQL-Q2

А вот зачем нужен глупый флейм на форуме - мне непонятно. Видно кто-то очень хочет таким образом самореализоваться.

>>на этот счёт существует более одного мнения. Например - условие
>>целостности -- значение поля А должно быть всегда равно сумме значения
>> полей Б и В или там дата должна быть обязательно рабочим днём. Все
>> равно его придётся запихивать в приложение.

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

В нормальной БД любые варианты целостности данных реализуются средствами самой БД.

> В нормальной БД любые варианты целостности данных реализуются средствами самой БД.

Надо же такое совпадение - и в нормальном application server
это делается ;)

А как в сервере приложений реализуются 4 типа изоляции транзакций? Спрашиваю без подковырки.

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

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

Замачательно. Давайте "мухи отдельно, котлеты отдельно". Контроль за целостностью чего? Разве обязательно транзакции сервера приложений связаны с транзакциями СУБД?

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

Несусветная глупость. Дело сервера приложений обрабатывать данные, а хранить их и контролировать их целостность должна СУБД.
Это все ущербный MySQL так заставляет людей думать ;)

1) Разве IBM WebSphere не может использовать в качестве контейнера для Entity Beans MySQL 3.23? Поддержка транзакций средствами СУБД отдельно, поддержка транзакций средствами сервера приложений отдельно.

2) MySQL >=4 поддерживает транзакционность :

create table acmetable(int i) type=InnoDB;

create table acmetable2(int i) type=BDB;

Только давайте не мешать в кучу транзакции СУБД и сервера приложений, который, в общем случае, может работать и без СУБД.

Sorry,

create table acmetable(i int) type=InnoDB;

create table acmetable2(i int) type=BDB;

set autocommit = 0;

insert into acmetable values(1);

select * from acmetable;

rollback;

select * from acmetable;

Проверяйте.

А VIEW в MySQL есть? ЧТо-то читаю доку, не вижу упоминаний

>Это все ущербный MySQL так заставляет людей думать ;)

Не.

Это идея-фикс маркетологов в середине 90-х. MTS, Байконур... в конце концёв, этот мутный вал вроде схлынул, "но осадок остался" :)

Триггеры... триггеры вещь отчасти хорошая... обовляемые представления и всё такое... но уж больно тяжелая артиллерия. Это же процедурный язык нужно заталкивать в СУБД... А зачем? Если уже есть какойнить perl-php...

Отсутсвие транзакций и проч. даёт (должно давать по идее - незнаю, как на самом деле, выигрыш по скорости на обновлениях). Твой, видимо любимый Oracle, в своё время тоже игрался с подобным -- Oracle Lite (одна dll, в 200 кило) - там правдо много чего было (и почти всегда работающие транзакции).

С другой стороны - подход MySQL'евцев -- движок SQL отдельно, хранилище данных (перусловутая innodb, вкупе с db, isam,myisam и что там у н их ещё) - отдельно, тоже имеет свои прелести. В том же биллинге, можно собирать данные из ulog'а в какуюнить производительну. isam-таблицу, а работать с деньгами в innodb-таблицах. Красиво, на правда ли?

Вот только вопрос, что будет с innodb-таблицей (а равно и постгрессовской), если счёлкнуть рубильником посередине между BEGIN и END. ...если незавершённая транзакция не откатится при старте базы, то...

флейм must go on

anonymous (*) (2003-09-17 10:23:13.758558):

> но вот нафига мне для телефонной книги использовать постгресс я пока не понимаю :-)

хех. а нафига для телефонной книги нужен MySQL --- стало быть понимаешь? ;]

dsa (*) (2003-09-18 13:17:01.628412):

> Это же процедурный язык нужно заталкивать в СУБД... А зачем? Если уже есть какойнить perl-php...

В постгресе есть pl/perl и (бета) pl/php. :]

> В том же биллинге, можно собирать данные из ulog'а в какуюнить производительну. isam-таблицу, а работать с деньгами в innodb-таблицах. Красиво, на правда ли?

Красиво, только вот внешний ключ с isam таблицы на innodb не работает.

> Вот только вопрос, что будет с innodb-таблицей (а равно и постгрессовской), если счёлкнуть рубильником посередине между BEGIN и END. ...если незавершённая транзакция не откатится при старте базы, то...

В постгресе точно откатится, в innodb скорее всего тоже.

>>Триггеры... триггеры вещь отчасти хорошая...
>>обовляемые представления и всё такое...
>>но уж больно тяжелая артиллерия.
>>Это же процедурный язык нужно заталкивать в СУБД...
>>А зачем? Если уже есть какойнить perl-php...

Есть какойнить.
А вот есть база и куча приложений на терминале, под win, чере web,
а завтра надо будет под какойнить poket и буду я всю логику таскать ?
Написал триггер сказал CONNECT, INSERT и по барабану как он это сделает

>Вот только вопрос, что будет с innodb-таблицей (а равно и постгрессовской), если счёлкнуть рубильником посередине между BEGIN и END. ...если незавершённая транзакция не откатится при старте базы, то..

Я проверил. Откатывается.

Для справки dsa - это форумный клоун, у которого началось осеннее обострение. :)))))

Дык что бы рядом с Ораклом смотрелся нормально, MySQL купила SAP DB и обзывает теперь его MaxDB. Подробности вот тут http://www.mysql.com/sapdb/

MySQL - рулит!

Вот меня удивляет какого хрена на каждый пост новости о MySQL идёт откровенно грязное письмо от какого-нибудь студента в его адрес? Как только с таким студентом начинаешь разговаривать _по_существу_ оказывается, что у каждой БД своя ниша, и т. д. и т. п., но вот обосрать вначале - это обязательно... Похоже это комплекс какой-то у тех, кто MySQL не пользуется - ну не хочется в ещё одной базе разбираться, преимущества её понимать и начинают "да куда ей до [sencored]"! Не знаете - молчите!

Я кажется понял в чём фишка - проблема в том, что новости MySQL на LOR действительно часто - а все остальные OS базы - раз в год по чайной ложке!

anonymous (*) (2003-09-18 20:27:18.745759)

> Похоже это комплекс какой-то у тех, кто MySQL не пользуется - ну не хочется в ещё одной базе разбираться, преимущества её понимать и начинают "да куда ей до [sencored]"! Не знаете - молчите!

Да, разбирать (вернее разгребать) её преимущества действительно долго. Спасибо людям, которые это за нас делают: http://sql-info.de/mysql/gotchas.html

anonymous (*) (2003-09-18 20:35:54.133959):

> Я кажется понял в чём фишка - проблема в том, что новости MySQL на LOR действительно часто - а все остальные OS базы - раз в год по чайной ложке!

Ну ещё бы, коммерческая компания, специально оплачиваемые люди пресс-релизы пишут и статьи в продажные журналы.

> Да, разбирать (вернее разгребать) её преимущества действительно долго. > Спасибо людям, которые это за нас делают: > http://sql-info.de/mysql/gotchas.html

Да уж читали... Таких "gotchas" можно найти у любой базы - и преимуществами они не являются, не надо подменять топик! Из серьёзных я кстати там вижу только один - VARCHAR && SPACES. Только вот этот gotcha и у ORACLE есть, но как же, ORACLE велик и крут, его обсирать нельзя...

> Ну ещё бы, коммерческая компания, специально оплачиваемые люди > пресс-релизы пишут и статьи в продажные журналы.

Меня это не волнует лично - я пользуюсь бесплатно и зарабатываю себе на этом на хлеб с маслом (поэтому и здесь флеймлю отчасти).

anonymous (*) (2003-09-19 02:26:48.070195):

> Из серьёзных я кстати там вижу только один - VARCHAR && SPACES. Только вот этот gotcha и у ORACLE есть, но как же, ORACLE велик и крут, его обсирать нельзя...

Из серьёзных --- а Оракл случаем не считает себя умнее DBA, как это делает Мыскль?

2.1 Silent Column Specification Changes

MySQL reserves the right to silently change column specification when creating a table:

"If you want to see whether MySQL used a column type other than the one you specified, issue a DESCRIBE tbl_name statement after creating or altering your table."

http://www.mysql.com/doc/en/Silent_column_changes.html

Possible consequences of this are left to the reader's imagination.

anonymous (*) (2003-09-19 02:30:56.270256):

> я пользуюсь бесплатно и зарабатываю себе на этом на хлеб с маслом (поэтому и здесь флеймлю отчасти).

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

PostgreSQL vs MySQL

http://www.commandprompt.com/images/mammoth_versus_dolphin_500.jpg

А вот была раньше такая СУБД db_Vista (нынешний уродец-мутант BirdStep не в счёт). Даже любимая мною MySQL отдыхает...