dalex писал(а):Я вообще не понимаю применение этой СУБД для такого проекта. Для, для UTM3/4 мыскль еще был применим, но сейчас эта записнушка с SQL-like интерфейсом на серьезной нагрузке начинает явно сдыхать.
есть другой вариант?
и если можно по пунктам чем мускуль не устраивает а не взрыв эмоций
Этот другой вариант давным-давно существует, и даже поддерживается в UTM5. Правда в виду ущербности мыскля этот второй вариант разработчики не используют в полную силу.
В каком качестве сейчас используется СУБД в биллинге? А СУБД сейчас используется только в качестве хранилища данных. Больше мыскль дать принципиально не может. Разговоры про хранимые процедуры в мыскле ведуться уже много-много лет, а где результат? При том при всем даже при весьма недолгом изучении DEBUG'а видно, что весьма нехилую часть обработки данных можно переложить на сервер СУБД, повысив общую производительность систему в целом. А так же повысить уровень сохранения непротиворечивости данных.
Где в мыскле транзакции? Не надо мне рассказывать про не те используемые форматы таблиц. Как не было рельных транзакций в мыскле, так они и не появились до сих пор, а те что имеются на уровне блокировок BDB4.
Целостность и непротиворечивость хранимых данных. Что-то я за все время не встречал халоб на то, что у кого-то БД на PG екнулось настолько лихо, что похоронило расчетный день. В случае же мыскля самым действенным советом при появлении неопознаваемых глюков является man mysqlcheck, и самое смешное, что этот совет в 9 случаях из 10 помогает. В последнем случае помогает полное восстановление из бэкапа, но не факт, что в бэкапе окажется живая база, вполне может оказаться, что какая-то таблица затерялась еще неделю, месяц назад.
Небольшой пример:
http://npj.ru/cake. Именно его я ставлю своим клиентам по конторам для учета траффика. Хоть и функционалом он с UTM не ставнивается, но то, что ему положено делать, он делает от и до. При том сами размеры поделки смешные, вся логика работы прописана в PL/PG хранимыми процедурами. Системы экплуатируются в весьма суровых условиях (откровенно слабые машины и никаких гарантий по стабильности питания). И ни разу, _НИ_РАЗУ_ не возникало проблем из-за того, что подвела СУБД (рухнул индекс, осыпалась таблица, намертво залочилась запись).
