Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8   вперед  Ctrl      все
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
MBG

Предложение подтвердить свои утверждения доказательствами. Утверждение, что СУБД лучше, потому что она "взрослая" - это детский сад какой-то.


http://www.sqlite.org/whentouse.html
SQLite uses reader/writer locks on the entire database file. That means if any process is reading from any part of the database, all other processes are prevented from writing any other part of the database. Similarly, if any one process is writing to the database, all other processes are prevented from reading any other part of the database.

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

MBG
Бедный оракл - не посоветовался с вами, покупая файловую СУБД BerkeleyDB, а теперь тратится на ее развитие. А в последней версии еще и движок эскулайта интегрировали для поддержки SQL. Срочно звоните Ларри Эллисону - сообщить, что вы с ним не согласны... Заодно предложите in-memory СУБД TimesTen выкинуть, которую они тоже купили, не посоветовавшись с вами.

хи-хи, по вашему это покупалось на замену ораклу ?
боже, до меня только, что дошло - последним покался innodb, значит именно он заменит все субды оракла разом
13 апр 10, 19:55    [8624232]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6645
MBG
Siemargl

Интересно, а как обстоят дела с резервированием?

У кого как. У меня лично - утилита sqlite3-rdiff Для синхронной репликации тоже можно сделать, просто руки не дошли пока, не было надобности.

Если на ходу сдохнет сервер биллинга с 32Гб незаконченных транзакций, сколько ж это будет в невзятых деньгах с клиентов?? :-)

MBG

Siemargl

В том то и разница, что в клиент-сервере прямого доступа к файлам БД нет никогда. И даже с сервера, потомо что открыты эксклюзивно.

Дайте мне рутовый доступ к вашему серверу, и посмотрим, сколько секунд мне понадобится, чтобы прибить все ваши "эксклюзивно открытые" файлы БД.

Это на линухе. На винде, где я живу, такой фокус без прибития процессов не пройдет=)

2ЛП. А что же такое БерклиДБ, по Вашему ? )

Йо! К сожалению, Оракл в каждую дырку не засунешь - не пролезет, как тот Винни-Пух =) Файловые БД имеют свою нишу в эмбеддед ~
13 апр 10, 23:36    [8624916]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Vinny the POOH
Member

Откуда: Киев
Сообщений: 1525
Siemargl

Это на линухе. На винде, где я живу, такой фокус без прибития процессов не пройдет=)


Имея рутовый пароль к чему угодно, прибить процессы особо то никто и не мешает. Да и жизненно важные сервисы на венде никто не держит, разве что полные извращенцы. Идеология всей системы ущербна, сколько костылей на неё ни вешай.
14 апр 10, 00:38    [8625035]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6645
Vinny the POOH,

Может и ущербна. Но не так много людей точно знают места ущербности =) Особенно с серверной стороны. А скорость подтянули за 10 лет.
14 апр 10, 00:48    [8625049]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Vinny the POOH
Member

Откуда: Киев
Сообщений: 1525
Siemargl
Vinny the POOH,

Может и ущербна. Но не так много людей точно знают места ущербности =) Особенно с серверной стороны.


Не многие знают, но кто знает - использует на всю мощь, ворочая многомиллионными ботнетами. "Серверная" от "клиентской" отличаются лишь ценой, комплектом "ПО" и дефолтными настройками. Ядро - одно и то же. Ядро и всякие КОМы, Tridentы и прочий дырявый шлак, запиленный в него намертво - везде одни и те же. Недаром ведь по моей статистике 90% спама прёт либо с вендовых затрояненных вендовых машин либо с затрояненных же вендовых серваков. Недаром же все знакомые сотрудники датацентров лютой ненавистью ненавидят вендовые колокейшн-сервера из-за того, что с ними больше всего гымора в плане перезагрузок и блокировок в связи с нивротъибенным спам-трафиком.

А скорость подтянули за 10 лет.

Не скорость подтянули, а аппаратные мощности. Скорость упала на несколько порядков: попробуйте-ка поставить какой-нить 2008R2 на железо 2004 года выпуска? Оно там хоть заведётся? А Линукс 2009 года - не просто заводится, а держит достаточно неплохую нагрузку, и не требует внимания ровно до первого отказа железа. Какая венда способна таким похвастаться? А какая венда может похвастаться тем, что она управляет котлами, разводными мостами, авиационными диспетчерскими станциями, ядерными реакторами?... Да блин, задолбали эти споры. Непригодна венда к серьёзным ТЕХНОЛОГИЧЕСКИМ задачам, и всё тут. Да, как игровая приставка - самая идеальная система, для этого она и делалась. Сидели бы M$ в своей нише игр и мультимедиа - всем бы щастье было, это у них хорошо выходит. Но нет же - полезли в корп.сектор, и наделали мегатонны геммороя, за что им - лучи ненависти.

Эх простите, если кого обидел, но просто не могу я, блин, читать весь этот гнусный пеар венды и вендорешений как "надёжных" и "недорогих" средств организации корпоративной инфраструктуры. Ложь и ересь, причем от начала и до конца. А я, блин, правду люблю.
14 апр 10, 01:21    [8625086]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6645
Vinny the POOH
А какая венда может похвастаться тем, что она управляет котлами, разводными мостами, авиационными диспетчерскими станциями, ядерными реакторами?

Можете смеяться, именно этим я и занимаюсь.
И кроме того, нет для этого систем, кроме винды. Для OS/2 последняя SCADA померла 3 года назад, для QNX домирает. Для остального и не было.
Не знаете, так не {звез}$%ъдите.
14 апр 10, 01:41    [8625105]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6645
А насчет недорогих соглашусь. Дорого тут все. Аппаратное резервирование только чего стоит. И перспективы удешевления пока нетути :)~
14 апр 10, 01:44    [8625108]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
2 Siemargl
2ЛП. А что же такое БерклиДБ, по Вашему ? )

Обычная нереляционная embedded субд
Отнести её к файл-серверным, при том что там вроде как даже сетевого кода нет ни грамма - это надо очень извращенной фантазией обладать.

К сожалению, Оракл в каждую дырку не засунешь - не пролезет, как тот Винни-Пух =) Файловые БД имеют свою нишу в эмбеддед ~

Это не файл-серверные СУБД имеют свою нишу в embedded.
Это embedded имеют свою нишу. Локальные однопользовательские базы данных сложностью чуть выше телефонной книжки. А уж ФС в эту нишу как могут влезают. Потому как нигде больше все эти аксесы, фокспры, и т.п. - просто нафиг не нужны.

И никто не хочет пихать в эту дырку оракл. Пусть бы в этой дырке сидели специально созданные для этой дырки embedded и нашедшие там свой последний приют ФС. Однако ж нет, выползают выползни со своими адептами-мозговыми слизнями, хотят захватить весь мир. Можно ли остановить выползание выползней из дыры - тот еще вопрос. Взять в руки окуенную хиянку, и хотя бы даже и ораклом дыру наглухо заколотить. Жалко конечно оракл, но ведь для дела.

----------------------

2 Vinny the POOH
Не скорость подтянули, а аппаратные мощности. Скорость упала на несколько порядков: попробуйте-ка поставить какой-нить 2008R2 на железо 2004 года выпуска? Оно там хоть заведётся? А Линукс 2009 года - не просто заводится, а держит достаточно неплохую нагрузку, и не требует внимания ровно до первого отказа железа. Какая венда способна таким похвастаться?

Линуксы со своими гламурными кедами и прочей эпидерсией по прожорливости обогнал уже даже висту. Чего, как мне казалось раньше, сделать невозможно в принципе.
А 2008R2 таки запускается и шустренько шуршит на весьма говённеньком железе.
Так что, как уже сказали - не знаете, так не {звез}$%ъдите.

Да блин, задолбали эти споры. Непригодна венда к серьёзным ТЕХНОЛОГИЧЕСКИМ задачам, и всё тут.

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

Сидели бы M$ в своей нише игр и мультимедиа - всем бы щастье было, это у них хорошо выходит.

Сидели бы юнихи, линухи, и прочая занимательная педерастия в своей нише высокопроизводительных серверов - и всем щастье было бы. У них это хорошо получается. Нет же, лезут куда-то на десктопы, с криками "теперь и под линухом можно читать книжки, смотреть киношки, лазить по интернетам, читать почту, вах как круто, всё что нужно для домашнего пользования".
Тьфу на эту занимательную педерастию с пингвиньим лицом. Тьфу на неё еще раз.
14 апр 10, 04:03    [8625144]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
ЛП
2 Siemargl
2ЛП. А что же такое БерклиДБ, по Вашему ? )

Обычная нереляционная embedded субд
Отнести её к файл-серверным, при том что там вроде как даже сетевого кода нет ни грамма - это надо очень извращенной фантазией обладать.


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

P.S. А эмбеддед клиент-серверных не бывает, как упыря.
14 апр 10, 13:14    [8627848]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
MBG
С какого перепугу вы приравниваете файловые к файл-серверным? Файл-серверные и файловые эмбеддед - два разных подкласса файловых СУБД.

Ждал этого вопроса
И что же такое "файловые СУБД"?
БД, которые хранят данные в файлах?
Дык они все там данные хранят. За редкими исключениями (кои умеют хранить данные прямиком на сырых партишенах, безо всяких там файлов).
Даже не к ночи упомянутые in-memory таки файлы используют, да.
Эксель - файловая БД?

В принципе конечно под "файловыми СУБД" можно понимать СУБД-нашлёпки поверх файловых систем (здрасть, товарисч Siemargl со своей Кэтрин). Здравые мысли в таком подходе есть. Но к упомянутой BerkeleyDB оно опять таки никакого отношения не имеет.
14 апр 10, 13:28    [8628006]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Siemargl

Если на ходу сдохнет сервер биллинга с 32Гб незаконченных транзакций, сколько ж это будет в невзятых деньгах с клиентов?? :-)


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

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

Siemargl

Это на линухе. На винде, где я живу, такой фокус без прибития процессов не пройдет=)


И процессы прибьем. Любой мало-мальски современный вирус еще не то умеет - справляется с десятками антивирусов и файрволов, маскируется, прописывается в реестр и т.п. - и файлы ваших БД повредить сможет, не рассчитывайте его "напугать" блокировками.
14 апр 10, 13:42    [8628188]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
ЛП

Линуксы со своими гламурными кедами...


КДЕ и под винды давно работает (с версии 4.0), причем тут линукс? :-)
14 апр 10, 13:59    [8628400]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6645
MBG,

Я не придираюсь. Вспомнились времена, когда у сотовых операторов на Новый Год биллинг дох. И до выхода на работу их Айтишников все было бесплатно )

В любом случае, чем меньше писать руками, тем лучше.

Деньги заказчиков считать не будем. Если сами решат, что тиражное изделие в эксплуатации даст больший эффект, чем самописный кластер, то так тому и быть. Уж больно дорогое время простоя может оказаться. См.пример про Н.Г.

MBG
P.S. А эмбеддед клиент-серверных не бывает, как упыря.

А FB Embedded ? )))

Про проблемы в безопасности Windows можно начать забывать, особенно в серверах. Начиная с Висты/2008. Оставшаяся дыра в OLE эволюционно вытесняется вполне безопасным дотнетом.
14 апр 10, 14:07    [8628493]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
ЛП
MBG
С какого перепугу вы приравниваете файловые к файл-серверным? Файл-серверные и файловые эмбеддед - два разных подкласса файловых СУБД.

Ждал этого вопроса
И что же такое "файловые СУБД"?


Представляют собой библиотеки доступа к файлам, простейший вариант - к flat-файлам. Эмбедед - когда вдобавок исполняются в адресном пространстве приложения, т.е. обычные динамические библиотеки или вкомпилированы непосредственно в приложение. Берклидб или эскулайт - это библиотеки, а не сервера или приложения. Под виндой есть существенная разница между доступом к локальным и удаленным файлам, потому и появился подкласс "файл-серверных" (когда файлы БД физически размещаются на удаленной машине), и подкласс эмбеддед (файлы БД доступны локально). В других ОС работа с удаленными и локальными файлами полностью идентична и понятие "файл-серверный" лишено смысла, так что файловые и эмбеддед принципиально не отличаются.

http://ru.wikipedia.org/wiki/Система_управления_базами_данных
Файл-серверные
В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. СУБД располагается на каждом клиентском компьютере (рабочей станции). Доступ СУБД к данным осуществляется через локальную сеть.

Встраиваемые
Встраиваемая СУБД — библиотека, которая позволяет унифицированным образом хранить большие объёмы данных на локальной машине.


В линуксе, план9 и многих других ОС эти определения бесполезны. Как пример, у меня на ноутбуке сейчас примонтированы файловые системы пары серверов и я работаю с их файлами как с локальными, хотя один из указанных серверов находится от меня за полстраны. И эмбеддед СУБД эскулайт, запущенная в процессе на моей машине, может оперировать данными, физически расположенными в Москве или Нью-Йорке или с теми и другими одновременно.

Добавив к файловым СУБД сетевой интерфейс, получим клиент-серверные. Например, sqlite + sqlrelay - это уже клиент-серверная СУБД. Соответственно, используя свой сервер приложений плюс эмбеддед СУБД, мы получаем решение, полностью заменяющее клиент-серверные СУБД, а за счет отказа от большого количества "универсального" кода получаем выигрыш в эффективности системы.
14 апр 10, 14:30    [8628731]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
2 MBG
Под виндой есть существенная разница между доступом к локальным и удаленным файлам, потому и появился подкласс "файл-серверных" (когда файлы БД физически размещаются на удаленной машине), и подкласс эмбеддед (файлы БД доступны локально).

Чушь.
Файл-серверные СУБД появились задолго до винды.
Равно как и клиент-серверные.
Равно как и встраиваемые.
Идите хоть историю поучите, раз уж с информатикой не сложилось.

В других ОС работа с удаленными и локальными файлами полностью идентична и понятие "файл-серверный" лишено смысла, так что файловые и эмбеддед принципиально не отличаются.

Чушь.
Какой-нибудь Filemaker бррр под MacOS при всём желании не назвать embedded. Самое что-ни на есть файл-серверное уродство.

Добавив к файловым СУБД сетевой интерфейс, получим клиент-серверные.

Три раза чушь. Даже комментировать нечего.
14 апр 10, 14:47    [8628885]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
MBG,

почитал блог, я правильно понял архитектуру ? я понял, что АТС пишет данные звонков в файлик на фс-сервере, параллельно по некому протоколу (tcp?) передает эти же данные в программу-коллектор. программа коллектор блокирует всю бд sqllite на любой доступ (в том числе и на чтение) и заливает пачку данных, после этого отпускает блокировку бд и бд "захватывает" следующий коллектор. так продолжается весь месяц, а с первого числа коллекторы начинают писать уже в новую бд, позволяя теперь "билинговать" старую бд, в которую уже ничего не пишется.
как-то не понятно как при таком раскладе хотя бы лимиты на звонки учитывать.
14 апр 10, 14:55    [8628939]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
roden
Member

Откуда:
Сообщений: 741
MBG
а за счет отказа от большого количества "универсального" кода получаем выигрыш в эффективности системы.

Типа SQlite на локальных машинах круче всех?
14 апр 10, 16:25    [8629769]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Yo.!
MBG,

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


Программа-коллектор опрашивает набор АТС одного типа, преобразует данные и пишет в едином формате в in-memory SQLite базу (кроме того, с АТС можно "сырые" данные в текстовые логи писать, если это так, то коллектор может эти данные отпарсить, если их "скормить" ему на stdin). Раз в N секунд каждый коллектор (число коллекторов равно числу типов АТС) пакетно заливает данные в дисковую SQLite базу, блокируя ее на время порядка десятков миллисекунд. Биллингатор работает с этой же базой одновременно с коллекторами. В итоге при десятке подключенных АТС и онлайн биллинговании база блокируется менее чем на 100 миллисекунд каждую секунду, так что блокировки никому не мешают. По истечению месяца база перестает изменяться и ее можно скинуть в архив на рид-онли носитель, удалить и т.п. (если основной биллинг и просмотр отчетов на разных хостах, то старые БД биллингу не нужны; притом, всегда можно восстановить старые периоды, скопировав БД с архивных носителей).

В общем-то, такая технология шардинга аналогична использованию табличных пространств, но намного удобнее в администрировании. Администратор СУБД для описанной системы вовсе не нужен, все автоматизировано. Плюс скорость работы системы сохраняется, независимо от объема данных (т.к. данные разделены по месяцам, нет разницы, хранятся данные за 1 месяц или за 100).
14 апр 10, 16:33    [8629858]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
roden
MBG
а за счет отказа от большого количества "универсального" кода получаем выигрыш в эффективности системы.

Типа SQlite на локальных машинах круче всех?


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

В тех случаях, когда нужно предоставить клиентам веб-интерфейс, зачастую нет смысла лишний уровень городить, да еще через tcp/ip, когда можно прямо из application server получить доступ к данным с помощью встраиваемых СУБД. Разумеется, есть и свои проблемы у последних - скажем, сложно обеспечить поддержку длительных транзакций, но для веб-приложений, тем более, использующих ajax, это просто не требуется. Клиент-серверы хороши именно для тех задач, где пользователи подключаются к терминалам и вручную выполняют запросы, зачастую продолжительные, - но со времен мэйнфреймов такой сценарий работы стал весьма экзотическим (да и для клиент-серверов сейчас почти всегда для запросов, занимающих минуты/дни/часы, создают отдельное хранилище данных, доступное лишь в режиме рид-онли).
14 апр 10, 16:47    [8630056]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6645
MBG
Эскулайт, берклидб и подобные на порядки быстрее клиент-серверов

что то это сильно мне напоминает это, только наоборот )))))))

Как дошло до тестов, проявляющих поведение в рабочих условиях, так сразу отступные речи...
14 апр 10, 18:34    [8630947]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Siemargl
MBG
Эскулайт, берклидб и подобные на порядки быстрее клиент-серверов

что то это сильно мне напоминает это, только наоборот )))))))

Как дошло до тестов, проявляющих поведение в рабочих условиях, так сразу отступные речи...


Там тесты однозначно показали, что ваш хэш массив в ОЗУ работает медленнее дисковой базы эскулайт. Что касается рабочей архитектуры, я несколько раз указывал, что основным ограничением является необходимость пакетной вставки данных для дисковой БД, из-за ограничений оборудования при использовании fsync. Можно отключить fsync и тогда нет нужды именно в пакетной вставке, но целостность БД нужно обеспечить внешними средствами (например, с помощью логирующей ФС или репликации). В обсуждаемом биллинге реализована именно вышеназванная техника пакетной вставки и многопоточного чтения, коды коллекторов можно в моем открытом деб-репозитории посмотреть.

Также периодически напоминаю об ограничениях на размер индексов и т.п. И тесты публикую - как можно нарваться на проблемы на миллионе записей и как можно получить высокое быстродействие на миллиарде записей. Иначе и молотком можно лоб расшибить, если пользоваться не умеете.
14 апр 10, 19:15    [8631144]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
долго пытался воткнутся как с таким убожеством можно что-то онлайн провернуть, решил копнуть и наткнулся на чудесный документ с гордым названием "Техническое описание программы MBG Биллинг". данное ТЗ поражает не сколько проработанностью, сколько техническими решениями авторов.

онлайн биддинг:
интернет услуги
2.1.2 Приостановление использования клиентом услуг Компании при отрицательном балансе (проверка баланса 1 раз в месяц).
2.2.3 Приостановление использования клиентом услуг Компании при отрицательном балансе (проверка баланса 1 раз в день).

телефонная связь
3.1.3 Пересчет денежного баланса клиента в зависимости от стоимости полученных им услуг Компании, рассчитанной в соответствии с установленными тарифами и зоны разговора (выполняется 1 раз в день или 1 раз в час).
3.1.4 Приостановление использования клиентом услуг Компании при отрицательном балансе (проверка баланса 1 раз в день или 1 раз в час).


Примечания по реализации:
примечания

4. Интернет-трафик агрегировать
4.1 по часам трафик по клиенту (база stat_yy_mm.db)
4.2 по дням по клиенту (база stat.db)
4.3 по дням по хосту и клиенту (база stat_yy_mm.db)
4.4 по месяцам по клиенту (база stat.db)


занавес.
14 апр 10, 22:12    [8631680]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6645
Yo.!,

Это что, у Оракла есть шанс отбить клиента, да?

ЗЫ. У нас биллинг с "мгновенным" перерасчетом дэдлочится (на Ора) периодически.
14 апр 10, 23:10    [8631769]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
навеяло
14 апр 10, 23:27    [8631786]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
Siemargl

Это что, у Оракла есть шанс отбить клиента, да?

в смысле шанс ? промышленные билинги бывают на чем то кроме оракла ?
14 апр 10, 23:31    [8631797]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 6 [7] 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить