Как насчет того, что бы сделать поддержку ORACLE,
это как-то понадежнее MySQL
ORACLE
МДА. того что бы ORACLE работал медленне MySQL я еще не слышал.dalex писал(а):руль это смешноКак насчет того, что бы сделать поддержку ORACLE,
это как-то понадежнее MySQLухожу домой радуясь.
Сколько там стоит лицензия оракла на коммерческую деятельность?
Оракл будет работать на UTM медленнее мускуля на порядок - на два на три. Выбор mysql-postgresql ИМХО оптимален.
А лицензия это уже другая проблема.
как вы думаете мерседес будет лучше трактора пахать?МДА. того что бы ORACLE работал медленне MySQL я еще не слышал.
я же сказал что для этого биллинга. Оракл нужен там где используются именно его возможности а здесь все просто поэтому простой mysql работает быстрее.
Плюс если нетаповцы будут делать биллинг на оракле им придется купить лицензию и тогда биллинг будет стоить несколько тысяч зеленых.
Я же не говорю заменить MySQL на ORACLEdalex писал(а): Плюс если нетаповцы будут делать биллинг на оракле им придется купить лицензию и тогда биллинг будет стоить несколько тысяч зеленых.
Если в нетап будет помимо MySQL включена поддержка ORACLE, то
кто не хочет тот пусть не использует, и сидит на MySQL,
а кому важна надежность и уже есть ORALCLE, будет использовать ORACLE.
ЭЭЭ, по моему несколько малая цыферька названа, нам насчитали больша 100 тыщ, и это при наших скромных запросахdalex писал(а):ясно же сказано что для создания коммерческих приложений под оракл нужна их лицензия а она стоит сотни тысяч зелени. И куда они эту затрату вложат? конечно же в стоимость биллинга.а кому важна надежность и уже есть ORALCLE, будет использовать ORACLE.
нужен оракл покупайте сибосс за 22000 зелени.
NetUP UTM 4.0 [1 +update 17 may 2004], NetUP RADIUS SERVER [], RH Linux 9.0
Да нет, буквально в конце февраля... Причем тулили свое оборудование, и не хотели делать на нашем... (точнее хотели, но просили не меньшую циферку)dalex писал(а): Давно это было наверно.
У них сейчас кризис я по дури письмо им отправил так меня их менеджер замучал и письма писал и звонил и т.п. предлагали инет+диалаап+воайпи за 22 тыс зелени.
NetUP UTM 4.0 [1 +update 17 may 2004], NetUP RADIUS SERVER [], RH Linux 9.0
В чем выражается "с postgres-ом-то работать еще добром не умеют" ?of писал(а):Блин... оракл.... они с postgres-ом-то работать еще добром не умеют, а вы говорите оракл.... да и какой смысл оракла который будет использоваться в режиме mysql.
Тему с кодировками я прочитал - суть понятна, но дело -то не в системе ... скорее всего надо настраивать postgresql. В частности в нем нет возможности задавать кодировку на отдельные таблицы. В mysql это есть Вот о том и речь, что в ответ на все проблемы с постгрес - вы твердите "в mysql это есть", однако давайте вдумаемся в суть проблемы: тип text я так предполагаю даже в mysql предусмотрен для хранения ТЕКСТОВЫХ ПЕЧАТНЫХ СТРОК а не для хранения ПРОИЗВОЛЬНЫХ ДАННЫХ, для хранения ПРОИЗВОЛЬНЫХ ДАННЫХ существуют совершенно другие типы данных, которые и в запросах отображаются соответствующим образом (например в postgres это bytea).aospan писал(а):В чем выражается "с postgres-ом-то работать еще добром не умеют" ?
Даже теоретически если-бы в postgres И была возможность выставлять кодировку для отдельной таблицы - то при выводе
результатов запроса select id,value from dhs_access_log_attrs; в psql
можем получить такую комбинацию непечатных символов - которая напрочь снесет знакогенератор в консоли и у меня это уже не раз бывало, а вот при выводе результатов поля типа bytea все непечатные символы заэскейпятся.
Далее по поводу "с postgres-ом-то работать еще добром не умеют":
Тут я могу признать что "возможно я не прав имея ввиду то что имел ввиду". Причин тому несколько, для начала насколько я понимаю
вы не используете транзакций - поэтому при аварийном завершении
база может оказаться в любом состоянии и теоретически после рестарта возможно повторное списание или наоборот несписание средств. Далее - идеология баз более серьезных чем mysql предполагает вынесение части или даже всей бизнес-логики из приложения в базу.
Отдельный разговор о том, что я не знаю и даже не могу предполагать в худшую или лучшую сторону это скажется на производительности.
Ну и с постгресом я уже повидал столько косяков, что лучше-бы вы и не заявляли про поддержку постгреса чем каждый раз выслушивать что это постгрес такой плохой.
Один из глобальных косяков это проблемы постгреса с выборками типа select max(x); Которые он делает на несколько порядков дольше чем select x from y order by x asc limit 1; Я на соседней машине (куда пытался импортировать) завел базу на postgresql8.1, и "основной отчет" генерится все так-же долго а вывод select * from pg_stat_activity; все так-же показывает что все тормоза возникают в районе select max(x); Так что тут вам тоже надо править под постгрес, или у всех пользователей пользующих ваш биллинг будут тормоза, а в ответ на жалобы пользователи все так-же будут слышать "не мы такие, постгрес такой - пользуйте mysql".
Я достаточно ответил на Ваш вопрос?
Самый дешевый Oracle - Standart Edtion One стоит около 1200$dalex писал(а):руль это смешноКак насчет того, что бы сделать поддержку ORACLE,
это как-то понадежнее MySQL
Сколько там стоит лицензия оракла на коммерческую деятельность?
Оракл будет работать на UTM медленнее мускуля на порядок - на два на три. Выбор mysql-postgresql ИМХО оптимален.
Если запросы сложнее select'a к одной табличке, то Oracle здесь начинает выигрывать у mysql или pgsql. Просто не скупитесь на память для sql сервера. Но не в этом дело.
При большом объеме данных поддержка системы 24/7 на utm5 и mysql превращается в мазохизм. И если в системах порядка Oracle есть все средства для этого, то бесплатные СУБД только к этому подходят.
За исключением двух громоздких таблиц со списаниями со всем остальным справится хоть Access, хоть Clipper. При большом объеме данных растут эти таблицы, которые в любом случае нужно чистить. Детальная статистика по трафику вообще выносится за пределы базы и хранится в формате gigabase.
Ядро совершенно не использует возможности базы, не учитывает специфику ее работы. Во многих случаях оптимизация и разумное использование индексов увеличили бы скорость работы. Триггеры и хранимые процедуры уменьшили бы нагрузку на и без того не быструю жабоадминку. Так что Оракл будет действительно громоздким и дорогим решением.
Ядро совершенно не использует возможности базы, не учитывает специфику ее работы. Во многих случаях оптимизация и разумное использование индексов увеличили бы скорость работы. Триггеры и хранимые процедуры уменьшили бы нагрузку на и без того не быструю жабоадминку. Так что Оракл будет действительно громоздким и дорогим решением.