ТурбоБухгалтер будет портирован на Linux

Бля двигаться на линукс надо постепенно на самом деле так. А именно административными мерами дать пизды тем кто создает кривые системы. Я уже говорил у нас для бугалтеров клиент-серверная система занимает на клиенте 70 мегов.Ей гигагерц минимум надо для того чтоб нормально шевелиться и 128 памяти. Иначе тормозит по черному. Не вижу я никакого оправдания таким системам из-за одного только - "чтоб интерфейс был знакомый".

Кхм ты шутник?Мускуль и постгрес на бухучет?(насчет последнего может быть и можно).Но лучше ораклу - как то надежней себя чувствуешь.

Нет, я не шутник. не надо мне Оракла. А что... если использовать в качестве сервера БД тот же MySQL - это как то ущербно? Вроде немало уже им пользуются и многих устраивают. Хранимые процедуры- доделают, я просто уверен. Транзакции- уже что-то там в InnoDB они вроде прикрутили. Че все помешались на Оракле то? Я не хочу платить бешеные деньги за Ораклы, я не миллионер, и фирма где я работаю не Audi называется :)

Насчет Хансы- я лично писал им запрос чтобы прояснить некоторые вещи по их типа крутой программе (демо под Линукс- ужастно вообще, и неудобно, и сыро как то все), они даже не удосужились ответить. Идут они нахуй с такой политикой. Вот и весь сказ.

Про мозиллу я просто ответил на вопрос. А MySQL - как-то несерьёзно. PostgreSQL на две головы выше. Одно дело - форум для веба делать, а другое - бухучёт. После того, как Mysql затёр соседние поля при попытке записи длинной строки в более короткое поле, я на него не перейду. А PostgreSQL - полноценный SQL-сервер (пусть без вложенных транзакций или ещё какой хрени).

Вообще говоря, от сервера для бухучета требуется высокая надежность, поддержка транзакций и хорошая система резервного копирования. Мне кажется что из GPL подходит SapDB
А Oracle, вы видели их цены? Лучше уж и не смотреть!

MySQL затер поля- дык надо было найти ошибку в коде сервера, сделать патч и отослать им :)) А если серьезно- а что ...в 1C надежность выше? там бывает такие приколы происходят- что затирание полей- это детский лепет. Но в 1С вообще никому ничего не докажешь, скажут- твои проблемы и гуляй Вася.

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

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

<цитата> После того, как Mysql затёр соседние поля при попытке записи длинной строки в более короткое поле, я на него не перейду.</цитата>

Чтооо? это у вас в какой версии такое? сколько помню mysql - никогда такой проблемы не было. Сейчас специально попробовал все доступные mysql (3.23.55, 4.0.9-gamma, 4.1.0-alfa) - нет такого..

У вас вероятно FS порушилась (или какая-то подобная беда случилась)

Неважно затер MySQL или не затер поле, все равно пока он в качестве корпоративной СУБД практически неприменим. Здесь важнее надежность а не скорость, а на MySQL транзакции только-только появились, да и резервное копирование на ходу практически невозможно. Правда если говорить положа руку на сердце и в M$ SQL это нормально не делается, похоже только Oracle справится на 100%.

Какой там постгрес, какой мускль. Бухгалтерию нужно держать
только в dbf. Проверено годами тестирования. Все
sql-бухгалтерии в той или иной мере сакс. Mysql для бухгалтерии
не годится вообще! Даже для программы-генерилки персональной
налоговой декларации. Это ж чемпион по количеству ошибок в
математических функциях.

> да и резервное копирование на ходу практически невозможно.

Хреновая у вас, значит, практика. mysqldump --opt DB_Name не подойдет случайно?

> Здесь важнее надежность а не скорость

А как ты узнал, что mysql менее надежна? У меня она годами
крутится без рестарта, и данные ни разу не пропали...

<цитата>Mysql для бухгалтерии не годится вообще! Даже для программы-генерилки персональной налоговой декларации. Это ж чемпион по количеству ошибок в математических функциях. </цитата>

Приведите пожалуйста примеры ошибок в математических функциях у mysql

Самая последняя - в функции round() в версии 4.0.x.

select round(9.765,2)
-> 9.76

а теперь внимание!

select round(9.775,2)
-> 9.78

Классно считает, да?

2 anonymous (*) (2003-01-11 23:16:12.991)

Нет такой способ не подойдет :)
При наличии активных "транзакций" на базе ты получишь копию с нарушенной целостностью. Проблема резервного копирования базы "на лету" гораздо серьезнее чем Вы это себе представляете.
Задайте себе вопрос - как сделать целостную резервную копию если на базе постоянно открыты транзакции?

2 anonymous (*) (2003-01-11 23:19:00.908)

У меня mysql тоже работает без проблем уже 2 года и данные тоже пока не пропали, но это на веб-сервере. Корпоративная СУБД более критична, там обязаны вестись транзакции и необходим копируемый журнал транзакций также нужна возможность резервного копирований на-лету.
Хотя mysql это конечно гораздо лучше чем dbf...

2anonymous (*) (2003-01-12 00:57:02.654)

Тогда еще раз man mysqldump. Опция --opt подразумевает в числе
прочих локировку всех копируемых таблиц на чтение.

> как сделать целостную резервную копию если на базе постоянно открыты транзакции?

Что значит постоянно открыты? В базе ничего не бывает
постоянно. Там все дискретно. Таблицы лочатся по очереди до
полной победы. Транзакции рано или поздно откатываются. И вот
он миг победы ;)

2 anonymous (*) (2003-01-12 01:25:14.186)

Постоянно - означает, что за время пока работает одна транзакция появляется хотя бы еще одна, и в результате нет такого момента, когда в базу не ведется запись.
Проблема с блокировкой таблиц в том, что ты фактически лишаешь всех пользователей возможности работать с базой на все время резервного копирования, а на большой базе это может происходить долго (например размер базы 5 Гб). Так то, естественно, можно организовать копирование любой базы, даже dbf или access (не ночью будет помянут).
А последовательно копировать таблицы не получится, транзакции обычно блокируют несколько таблиц и из этой сетки будет не выбраться. Да даже если и одну, ее то ведь будет не скопировать! Если интересно, посмотри как это сделано в Oracle, станет понятно откуда у этой проблемы ноги растут.

> это может происходить долго (например размер базы 5 Гб)
> [...] посмотри как это сделано в Oracle

Мне плевать, как это сделано в Oracle. И знаешь почему?
Потому, что в mysql резервное копирование такой базы будет
длиться 2 минуты ;) Мне даже жаль этих пользователей. Ни сигареты выкурить, ни кофейком побаловаться они не успеют ;(

anonymous (*) (2003-01-12 02:15:34.267)

То что тебе плевать как у них сделано, это уже наполовину диагноз :)
А по поводу скорости копирования, это хорошо что у тебя такая быстрая дисковая подсистема :) Но перерыв даже в 30 секунд порой бывает недопустим, ведь это надо проделывать несколько раз в день.

>> Ни сигареты выкурить, ни кофейком побаловаться они не успеют ;(

здоровее будут.

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

2 AVL2

Нет причин для беспокойства, mysql в таком случае ничего не грозит, на Oracle этой паузы вообще не будет, а потому пользователи не успеют даже вздохнуть :)

Oracle для автоматизации бухгалтерии, это конечно перебор по цене, но и mysql плохо подходит, вот может SapDB или FireBird ...

> это хорошо что у тебя такая быстрая дисковая подсистема :)

Эээ, а мы про что говорим? Про сервер или оракл крутится на
машине нелюбимой секретарши? ;))

> Но перерыв даже в 30 секунд

Заметь, база остается полностью доступна на чтение.
В тех местах, где критична остановка операций записи на 30 сек... Согласись, в таких случаях без запасного сервера все равно не обойтись. Сбой может произойти на уровне ядра ОС.
И остановка будет уже заметно больше, чем 30 сек. Так что твои
доводы не убедительны.

2anonymous (*) (2003-01-12 02:56:28.504)
> на Oracle этой паузы вообще не будет,

Ошибочное мнение. Оракл будет тормозить и без резервного копирования. Так что понятие "пауза" относительно. Представь,
запутил оператор транзакцию. На оракле она длилась 2 минуты,
на mysql - 2 секунды. А в оставшиеся 2 минуты mysql успел еще
и бэкап базы сделать... Так что все нормально ;)

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

2 anonymous (*) (2003-01-12 03:09:02.913)

Безусловно, поскольку в Oracle есть нормальная поддержка транзакций, в нем операции выполняются медленнее чем в mysql, но отнюдь не в 60 раз.
Подумай сам, за счет чего mysql быстрее? Не за счет ли того что в нем от чего-то отказались? А может быть это что-то даже очень полезная штука?
Ты представляешь как реализованы транзакции в Oracle (сегменты отката, журналы и т.п.) и какие возможности это дает? С mysql хорошо работать на веб сервере - там по сути один пользователь, все выглядит совсем иначе когда на базе активно работают десятки клиентов.

_периодическое_ резервное копирование делают ночью, в
обеденный перерыв, в конце рабочего дня. Это когда один
сервер и допустим простой в полчаса. Как раз и получается
_несколько_ раз в день ;) А то, что ты описал называется mission critical
и без бэкапного сервера с зеркалированием базы не обойтись.
Иначе фраза про 30 секунд выглядит как кривая шутка.

LOR во всей красе. Oracle vs. ..... MySQL ... да, друзья-маэскюэльщики, вы как не рядитесь, все в DBA не годитесь ;-)

> Ты представляешь как реализованы транзакции в Oracle (сегменты отката, журналы и т.п.)

Я одно знаю, что тяп-ляп программера это не спасет. Чтобы
все это добро работало лучше mysql нужны 1) высочайшего
класса программеры и проектировщики 2) доругущий админ
3) и много много бабок. При выполнении всех этих условий
возможно появление иллюзии некой стабильности. В противном
случае будет много много хуже ;) Фирма Оракл _не_гарантирует_
сохранность данных в вашей базе и _не_отвечает_ за любую
порчу вашей информации...

> Oracle vs. ..... MySQL

А с чего ты взял, что тут хвалят Mysql? Просто одно дерьмо (mysql)
воняет чуть меньше другого (oracle). Я вообще для себя
использую gdbm, в крайнем случае - dbf. Все остальное - от лукавого.

2 anonymous (*) (2003-01-12 03:48:52.857)

Вы пробовали ставить резервное копирование с остановкой базы в обеденный перерыв? Пользователи к сожалению строем в столовую не ходят! Реально такое копирование можно проводить _только_ ночью.
Я не говорю, что MySQL плохой, а Oracle хороший, просто MySQL пока не годится на роль корпоративного сервера.

Вот IMHO требования к корпоративному серверу:
1. Поддержка механизма транзакций
2. Возможность резервного копирования базы "на лету"
3. Копирование журнала транзакций с возможностью востановления на любое время.
4. Аутентификация и разграничение доступа (желательно иметь возможность централизованной аутентификации в ОС)
5. Триггеры, хранимые процедуры (язык программирования СУБД)
6. Поддержка SQL92 + дополнительные возможности (минимум нужны вложенные подзапросы, внешние объединения)
7. Возможность в одном запросе обращаться к нескольким базам на нескольких серверах
8. Репликация
9. База на нескольких дисках - табличные пространства

Надо-же, в требованиях к корпоративному серверу забыл указать:

0. Ссылочная целостность

   Самая последняя - в функции round() в версии 4.0.x.
   select round(9.765,2)
   -> 9.76
   а теперь внимание!
   select round(9.775,2)
   -> 9.78
   Классно считает, да?
Все правильно - считается что это более правильно чем округлять
всегда в одну сторону (то есть делают так - если посл. цифра - четная
- то ее оставляют, если нечетная - то увеличивают). Читай Кнута - у него
про это вроде написано.

2Behemoth. Надо же все, что перечислил есть в PostgreSQL. Пункт 7 пока не реализован, но можно выкрутиться (хотя скорость транзакций упадет сильно). с 8 пунктом сложнее, но можно. 9 без проблем, тут даже часть таблиц можно держать на другой машине.

Забавно смотреть как люди с mySQL гавкают на Oracle. Видно, что взяли за дорма Oracle, поставили на свою домашнюю машинку где и mySQL крутится, посмотрели с default установками. Словили тормоза, сказали Sux и удалили оставшись в полном моральном удовлетворении от mySQL :^) Иначе ни как не объяснить.

А вот почитать им как в Oracle устроены транзакции, целостность. Что особенно меня впечатлило в Oracle: возможность создания областей для отдельной группы/пользователя с ограничением по многим параметрам, получение любой информации по текущему, прошлому и предполагаемому будущему состоянию ДБ и ресурсов ОС, офигительная маштабируемость, и гибкость в настройках.

2Korwin:
   2Behemoth. Надо же все, что перечислил есть в PostgreSQL. Пункт 7 пока
   не  реализован,  но можно выкрутиться (хотя скорость транзакций упадет
   сильно).
Если не секрет - как этого можно добиться?
Спасибо.

> > 2Behemoth. Надо же все, что перечислил есть в PostgreSQL. Пункт 7
> > покане реализован, но можно выкрутиться (хотя скорость транзакций > > упадет сильно).
> Если не секрет - как этого можно добиться?
Где-то видел патч на это дело, но где не скажу. Потом, если набор таких SQL-запросов фиксированный, то можно сделать путем написания собственный функций в ДБ на C или TCL языке. Это проще в 7.3.x ветке, т.к. теперь функции могут более гибко возвращать множественые значения и выборки.

2hvv (*) (2003-01-12 13:25:36.218)

> Все правильно - считается что это более правильно чем округлять всегда в одну сторону

Расскажи такую сказку в налоговой инспекции ;)
А еще лучше выложи как-нибудь из своего кармана неправильно
округленную сумму налога в 9.765 млрд рублей ;))

2Behemoth (*) (2003-01-12 11:17:34.793)
Тут поступают реплики на счет того, что кто-то не видел оракла.
Но забывают, что кто-то очень давно не видел mysql ;)

Все, абсолютно все твои пункты давно реализованы в mysql.
7-ой пункт реализуется через application server, в котором
вообще можно сделать все, что угодно и гораздо меньшей кровью.
То, что ты будешь делать год, я сделаю за месяц.

<цитата> Расскажи такую сказку в налоговой инспекции ;) А еще лучше выложи как-нибудь из своего кармана неправильно округленную сумму налога в 9.765 млрд рублей ;)) </цитата>

;) А Вы деньги в double храните? Тогда проблем конечно не миновать. Вот здесь читать про такое поведение rand: http://www.mysql.com/doc/en/Problems_with_float.html и вот здесь тоже можно: http://www.mysql.com/doc/N/u/Numeric_types.html

Блин, да все это понятно. Вам же говорят, что проблема всплыла
когда появились ошибки в налоговых декларациях ;)
А на счет double я не понял шутку. Человек, ты с бухгалтерией дела имел?

2 anonymous (*) (2003-01-12 19:48:55.539)

Ты конечно крут :) и корпоративные системы пишешь за месяц и диски у тебя скоростные :)
Но вот только заявления о mysql ты в опрометчиво делаешь. Не знаю как в последних версиях mysql, а в той, которую я использую (3.xx) большинства этих возможностей нет. Действительно я давно не смотрел новые версии mysql. Приведи, pls, конкретную ссылку на описание этих возможностей. Я буду только рад если все так и есть (только что-то очень сильно сомневаюсь...)
Крайне интересен вопрос с аутентификацией, это действительно реализуемо? Очевидно нет, нормально реализовать централизованную аутентификацию в linux пока очень сложно.
Кстати, какой application server ты предлагаешь использовать, не Oracle, случайно :)?

<цитата> А на счет double я не понял шутку. Человек, ты с бухгалтерией дела имел?</цитата>

"Человек" имел дела с бухгалтерий. И даже очень. Поэтому и удивляется что кто-то использует _неточные_ типы данных для хранения такой информации, как деньги. Хотя бы decimal надо использовать для таких вещей. В любой СУБД. А то это неточность рано или поздно _где-нибудь_ да подведет.

Отрывок из документации по PostgreSQL:
  If you require exact storage and calculations (such as for monetary
  amounts), use the numeric type instead.

Type name  Storage size              Description                Range
numeric    variable      user-specified precision, exact      no limit

> _неточные_ типы данных для хранения такой информации

Да дело не в хранении, а в промежуточных вычислениях.
Сколько будет 25% от суммы 5003.9 руб? Реальный пример вычисления алиментов.

> заявления о mysql ты в опрометчиво делаешь. Не знаю как в последних версиях mysql

Ну прочитай, что ты написал. Не знаешь, но лезешь в обсуждение.
Бегом на www.mysql.com

Мда. Забавно звучат заявления что в mySQL все есть:
Upcoming Features
* Character set handling, with full Unicode support
* Expanded support for subqueries
Subqueries allow you to use the result of one query as a component of a larger query. The MySQL server already supports some forms of this technique, such as INSERT INTO ... SELECT ..., and this support will be expanded in version 4.1 to include nested SELECT queries, which is one of the most-requested features from our users.
* Stored procedures and triggers
Support for stored procedures and triggers will be introduced in version 5.0.
* Views
They can be used to grant limited access to tables, or make it easier to construct certain types of queries. Views are currently scheduled to be supported in version 5.1.

http://www.mysql.com/products/mysql/index.html

P.S.
Не флейма ради

> заявления что в mySQL все есть
Врете, батенька. В заявлении говорилось не про "всё", а только
про пункты, перечисленные г-ном Behemoth (*) (2003-01-12 11:17:34.793)

Господа, вы верите в халяву? Я - нет. Если пишут, что какая-то БД в 10 раз быстрее оракла, то

1) либо это ложь 2) либо эта скорость достигается образением всего что можно (и нельзя), включая контроль целостности, журналирование, транзакции и пр.

2 anonymous (*) (2003-01-13 08:26:10.702)

Ты говоришь, что все эти возможности есть в MySQL?
Это мягко скажем не совсем так:
- Триггеров, хранимых процедур нет
- Подзапросов нет
- Резервного копирования "на лету" нет
- Копирования журнала транзакций нет
- Централизованной аутентификации нет
- Возможности работы с несколькими серверами нет

Поддержка транзакций с помощью InnoDB это конечно лучше чем ничего, но все равно очень и очень слабо.
В любом случае MySQL ориентирован на скорость, а не надежность, и вероятно будет развиваться именно в этом направлении.

<cite>Да дело не в хранении, а в промежуточных вычислениях.</cite>

На упаковке процессора Pentium: Если этот продукт будет признан содержащим ошибки, производитель заменит его с уплатой $2 за пересылку и $3 за обработку посылки, всего за $4,97.

> Классно считает, да?

В теорим приближенных вычислений не изучали есть такое правило:

если первая отбрасываемая цифра 5, то последняя оставленная цифра должна быть четной.

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

Может, даже это и неправильно для бухгалтерии, но это не ошибка. Это фича!