Перевод бухгалтерии на Ubuntu, стоит ли?

[Lifewalker]

Один компьютер? Абсолютно бесполезная затея, более того — вредная с политической точки зрения.
Если бы вопрос стоял о минимум 10…15 машинах, тогда можно было начать думать над веб-мордой или чем-то ещё, а так… Бессмысленно.

[vktRus]

Лет через 5 может быть и переведу бухгалтера на Linux. А сейчас даже с организацией call-центра проблемы.

[Каметон]

Вопрос упирается в конечном итоге не в клиентскую часть, а в серверную, если в конторе много пользователей 1С (не только 1.5 бухгалтера, но и руководство, 20 менеджеров, экономисты и т.д.). Для простых задач пойдёт и веб-клиент. "Классический" толстый клиент, "ради которого стоит жить", пока под Линуксом нестабилен. И, главное, серверная часть, о которой все почему-то забывают, под Линуксом будет на postgreSQL, а она есть по сути переписка версии под MS SQL, т.е. это продукт вторичный, что неизбежно приводит к потере производительности и глюкам, да и админить такую систему сложнее, т.е. растут расходы на саппорт. Но если у вас клиенты под линуксами, а сервер под виндой, немного теряется смысл перехода и экономится только часть денег (в каждом случае, естественно, по-разному).

Поэтому рекомендовать переход 1С целиком на линукс (клиенты + сервер) можно только тем, у кого:
а) задачи не требуют большой производительности и стабильности, т.е. это уровень выше простого файл-сервера, но ниже мощного сервера под MS SQL;
б) у кого есть на примете хороший саппорт (например, адекватный грамотный сисадмин, который понимает и в 1С, и в линуксе на уровне эксперта).
в) Либо реально нет денег, либо жаба душит настолько, что "кушать не могу" (в этом случае приготовьтесь платить за саппорт чуть больше, но потом);
г) Задачи сотрудников ограничены использованием 1С, в том смысле, что отсутствуют подразделения, где используется MS Office на полную катушку, какой-то особый софт и т.д. (такая ситуация, надо сказать, встречается довольно редко).

[Отражение луны]

И, главное, серверная часть, о которой все почему-то забывают, под Линуксом будет на postgreSQL, а она есть по сути переписка версии под MS SQL, т.е. это продукт вторичный, что неизбежно приводит к потере производительности и глюкам, да и админить такую систему сложнее, т.е. растут расходы на саппорт.

Кто вам сказал такую чушь? 1с поддерживает множество SQL, в том числе MS и Postgres (например, вы забыли про Oracle). Платформа сама по себе позволяет абстрагироваться от того, какая СУБД используется в конечном счете. С таким же успехом можно утверждать, что версия с ms sql всего лишь переписка версии с dbf. ***

[Каметон]

Кто вам сказал такую чушь? 1с поддерживает множество SQL, в том числе MS и Postgres (например, вы забыли про Oracle). Платформа сама по себе позволяет абстрагироваться от того, какая СУБД используется в конечном счете. С таким же успехом можно утверждать, что версия с ms sql всего лишь переписка версии с dbf.

Во-первых, версия с MS SQL (еще первые ее потуги 8-ми летней давности) как раз и была тупой перепиской версии с dbf. Там клиент-сервер был очень странный, разработчики явно "учились на кошках". Потом, конечно, подтянули это дело и сейчас уже всё в порядке.
Во-вторых, платформа не может абстрагироваться от сервера полностью, поскольку промежуточный сервер 1С всё равно должен работать с каким-то конкретным сервером. И изначально это был MS SQL, под который всё заточено, а изменения для других серверов требуют кардинальной перестройки всего.
Например, тот же самый свободный Postgress в автомате использует режим табличных блокировок. Разработчики называют это "особенностями работы". Хотя понятно, что это ограничение, которого нет в MS SQL. А в DB2 получилась свистопляска с типами данных, что приводит к разным фокусам, типа невозможности выполнить некоторые запросы, которые можно выполнить на MS SQL. Не говоря уже про то, что 100% рабочую систему с MS SQL можно установить из коробки в полубессознательном состоянии, а всё остальное требует особой квалификации для решения проблем (причем иногда нерешаемых проблем).

Поэтому подтяните сначала матчасть, ***
___
Не надо принижать людей и провоцировать флуд. флуд - это посты не по теме или выражение эмоций.
модератор grad-data

[Отражение луны]

Во-первых, версия с MS SQL (еще первые ее потуги 8-ми летней давности) как раз и была тупой перепиской версии с dbf. Там клиент-сервер был очень странный, разработчики явно "учились на кошках". Потом, конечно, подтянули это дело и сейчас уже всё в порядке.
Во-вторых, платформа не может абстрагироваться от сервера полностью, поскольку промежуточный сервер 1С всё равно должен работать с каким-то конкретным сервером. И изначально это был MS SQL, под который всё заточено, а изменения для других серверов требуют кардинальной перестройки всего.
Например, тот же самый свободный Postgress в автомате использует режим табличных блокировок. Разработчики называют это "особенностями работы". Хотя понятно, что это ограничение, которого нет в MS SQL. А в DB2 получилась свистопляска с типами данных, что приводит к разным фокусам, типа невозможности выполнить некоторые запросы, которые можно выполнить на MS SQL. Не говоря уже про то, что 100% рабочую систему с MS SQL можно установить из коробки в полубессознательном состоянии, а всё остальное требует особой квалификации для решения проблем (причем иногда нерешаемых проблем).

Поэтому подтяните сначала матчасть, ***
___
Не надо принижать людей и провоцировать флуд. флуд - это посты не по теме или выражение эмоций.
модератор grad-data

Давайте я поясню, в чем именно вы ошибаетесь. 1C сервер со своим языком запросов и есть уровень абстракции. Он транслирует запросы в формат используемой SQL, поэтому говорить о "переписках" не корректно. В верной интерпретации проблема звучит так - "на данный момент существуют недочеты при использовании postgres". Это никоим образом не говорит о "вторичности" продукта - платформа таки развивается, и настанет время, когда эту проблему исправят. Мнимая вторичность продукта так же не приводит к воображаемым потерям производительность и глюкам, поскольку проблема реализации блокировок достаточно хорошо известна и по-моему даже документирована, а все остальное - просто ваши выдумки.
В целом по теме могу сказать:
1) Для малого офиса postgres подходит чуть более. чем полностью.
2) Для "среднего" офиса sql и 1с обязательно надо разносить на 2 разных сервера, поэтому на одном из них может стоять и венда со своим mssql, а на втором линукса и 1с сервер.
3) Известно несколько крайне положительных примеров хорошей работы связки 1c+oracle

[Gekko]

Аргументы "Отражение луны" звучат более убедительно, чем "Камертона".

[Каметон]

Давайте я поясню, в чем именно вы ошибаетесь.

В этом совершенно нет необходимости, поскольку я не ошибаюсь. Про трехзвеньевую архитектуру известно уже много лет, ее преимущества и недостатки тоже, поэтому объяснять ее принципы нет никакой необходимости, вопрос только в том, что сами по себе теоретические принципы не работают, их надо еще грамотно реализовать на практике. Вы зачем-то подменяете понятия, выдавая идеи за их реализации. Это некорректно.
На данный момент проблема звучит иначе: "невозможно комфортно использовать postgress для серьезной нагрузки" - причем я об этом сказал изначально. Т.е. MS SQL и postgress работают в итоге для конечного клиента по-разному, несмотря на дополнительный уровень абстракции. И обсуждать тут нечего, это факт. Проблема или "особенность" документирована, но она от этого факта не рассасывается. Чтобы ее решить, нужно переходить в режим управляемых блокировок, т.е. вносить изменения в конфигурацию. Концепция "один код на все сервера" предполагает явно иное.

Поэтому вынужден повторить: держите ваши выдумки о крутости связки Линукса и 1С при себе. Когда проблемы, которые вы сами признаете, благополучно разрешатся (вопрос еще в том, почему сразу их не решили; значит, с налёта не получилось), даю руку на отсечение, что я буду одним из первых, кто будет рекомендовать Линукс для 1С. Но пока делать это мне порядочность не позволяет (только с оговорками, которые я уже сделал).

P.S. По поводу Оракла не знаю, вполне возможно, что это и так. Решение новое, будем посмотреть. Но Оракл сам по себе стоит много. Т.е. экономическая составляющая тут не блещет и преимущество Линукса снижается.
Пользователь решил продолжить мысль 07 Сентября 2012, 17:29:32:

Аргументы "Отражение луны" звучат более убедительно, чем "Камертона".

Это потому что я не ориентируюсь на тех, кто по любому незначительному поводу кричит "он назвал Линукс земляным червяком". Просто привык к правдивому разговору.

[Gekko]

На данный момент проблема звучит иначе: "невозможно комфортно использовать postgress для серьезной нагрузки" - причем я об этом сказал изначально. Т.е. MS SQL и postgress работают в итоге для конечного клиента по-разному, несмотря на дополнительный уровень абстракции. И обсуждать тут нечего, это факт.

Никаких фактов не вижу, не убедительно. Больше похоже на мантру: "MS SQL, MS SQL, MS SQL, MS SQL ..."

Поэтому вынужден повторить: держите ваши выдумки о крутости связки Линукса и 1С при себе.

Больше похоже на зомбирование публики....

[Каметон]

Никаких фактов не вижу, не убедительно. Больше похоже на мантру: "MS SQL, MS SQL, MS SQL, MS SQL ..."

Факты уже были изложены (в т.ч. и в документации 1С, пожалуйста, потрудитесь это осознать еще раз). Если вы их не в состоянии понять (не хватает квалификации) - это нормально. Ненормально, когда кто-то пытается с апломбом судить о том, в чем не понимает.
Объясняю еще раз: постгресс при необходимости блокирует всю таблицу, в отличие от MS SQL, который блокирует отдельную запись. На практике это выливается в то, что при большой нагрузке на БД у клиентов возникают проблемы при работе с данными, т.к. один пользователь блокирует не свою запись, а целую таблицу (т.е. перекрывает доступ к ней всем). Это не проблема постгресса или достоинство MS SQL, это "особенность" работы сервера 1С. Логично, что в работе маленьких офисов или при слабой нагрузке это не вызывает проблем. Но об этом надо знать, эту проблему надо осознавать.

MS SQL, конечно, никакая не мантра, просто на данный момент 1С + MS SQL - это всесторонне рабочее решение. В отличие от других, которые нужно тестировать на слабые места (и с технической стороны, и, что немаловажно, с экономической), применительно к конкретной ситуации.

P.S. И еще раз повторю: я сам стараюсь не использовать продукты от MS где это возможно. Правило это вывел еще со времен 3.11. Но и фанатично бороться с любой программой от MS не вижу никакого смысла, особенно когда спор перерастает в очевидно идеологический, "назло Майкрософт маме отморожу уши". А уж когда дело касается бизнес применения софта, то при идеологизации вопроса тема плавно перетекает в сферу психологии (если не психиатрии).

[Gekko]

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

[Каметон]

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

Пожалуйста, начните всё-таки читать, что вам пишут. Я это вам советую абсолютно не во вред, поверьте. Про управляемые блокировки я написал чуть раньше, вы это не могли не видеть. Зачем повторяться тогда?
Вопрос в том, что управляемые блокировки требуют другого кода. Т.е. нужно переписывать некоторые куски, что нарушает концепцию "один код - много серверов". Это работает, если вы пишите свою конфигурацию с нуля. Как бы там ни было, нужна более высокая квалификация разработчика (соотв.,  растут расходы и риски на поддержку).

[Gekko]

И так мы пришли к заключению, что проблема заключается не в самой Postgresql а в том, что для того "Чтобы ее решить, нужно переходить в режим управляемых блокировок, т.е. вносить изменения в конфигурацию. Концепция "один код на все сервера" предполагает явно иное."
Таким образом, вы хотите сказать, что Postgresql хуже MS SQL Server потому, что не входит в понятие концепции "один код на все сервера". Не знаю, насколько вообще реализуемая эта концепция и насколько вообще разумно пытаться реализовать её, но могу предположить, что если бы в свое время фирма 1С изначально начала создавать архитектуру 1С предприятия не под MS SQL Server а под Postgresql а потом вздумала перейти на MS SQL Server, то вы бы так же говорили про MS SQL Server как сейчас про Postgresql, а именно:

MS SQL Server в автомате НЕ использует режим табличных блокировок. Разработчики (фирма Microsoft) называют это "особенностями работы". Хотя понятно, что это ограничение, которого нет в Postrgesql

На данный момент проблема звучит иначе: "невозможно комфортно использовать MS SQL Server для серьезной нагрузки" - причем я об этом сказал изначально. Т.е. MS SQL и postgress работают в итоге для конечного клиента по-разному, несмотря на дополнительный уровень абстракции. И обсуждать тут нечего, это факт.

[Каметон]

И так мы пришли к заключению, что проблема заключается не в самой Postgresql

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

Postgresql хуже MS SQL Server потому, что не входит в понятие концепции "один код на все сервера"

А тут вы опять перестали понимать. Не понимаете вы простой вещи: всегда рассматривается не сервер отдельно, ОС отдельно, 1С отдельно и т.д., бизнес всегда рассматривает решение на базе того-то и того-то, как совокупность компонентов. Вот эта куча софта VS другой кучи софта. Поэтому сравнение только Postgress/MS SQL в данном случае не имеет никакого смысла.

если бы в свое время фирма 1С изначально начала создавать архитектуру 1С предприятия не под MS SQL Server а под Postgresql а потом вздумала перейти на MS SQL Server, то вы бы так же говорили про MS SQL Server как сейчас про Postgresql

Даже если представить себе параллельную Вселенную, где это произошло, то в этом ничего удивительного нет. Изначально понятно, что перенос кода под другую платформу всегда чреват как минимум большим количеством недочетов и ошибок, а как максимум - проблемами, ограничивающими функционал. И если бы так было, то перенос кода с Postgress под MS SQL вполне мог вызвать какие-то свои проблемы. Что вы здесь нашли удивительного или компрометирующего?

Я могу вам предоставить более понятный пример, браузер Опера, скажем. Я этот браузер использую очень давно. Под виндой был всё время на нем. После того, как перешел на Линукс, тоже стал его использовать. Каково было моё разочарование, когда я увидел, насколько версия под Линукс хуже виндовой (при практически одинаковом интерфейсе). Сейчас, конечно, всё не так плохо, но несколько лет назад положение было ужасным. Вот вам пример того, что на словах софт "кроссплатформенный", а на деле - куча "особенностей".

[Gekko]

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

Но если вы пришли к этому заключению еще несколько лет назад, чего же вы в этом посте: https://forum.ubuntu.ru/index.php?topic=189431.msg1520934#msg1520934  говорите, что "Разработчики называют это "особенностями работы". Хотя понятно, что это ограничение, которого нет в MS SQL" ? Если бы это было ограничение, то не было бы второго режима о котором я говорил выше, режима управляемых блокировок в транзакциях, когда используются блокировки записей и полей а не всего и вся. Таким образом, ограничения о котором вы говорите нет. Но вы не смотря на это и не смотря на то, что уже несколько лет назад знаете, что в Postgresql есть 2 режима, сообщаете публике, о том, что в Postgresql есть ограничения, которых нет в MS SQL.

А тут вы опять перестали понимать. Не понимаете вы простой вещи: всегда рассматривается не сервер отдельно, ОС отдельно, 1С отдельно и т.д., бизнес всегда рассматривает решение на базе того-то и того-то, как совокупность компонентов. Вот эта куча софта VS другой кучи софта. Поэтому сравнение только Postgress/MS SQL в данном случае не имеет никакого смысла.

Нет в данном случае, как раз речь идет о сравнении только Postgress/MS SQL потому, что 1С использует именно эти две СУБД в своих системах, а мы говорим об 1С а не о фотошопах, MS Офисах и прочей "совокупности компонентов" которые не относятся к 1С. Вы изначально говорили, что 1С не будет нормально работать с Postgresql потому, что Postgresql хуже, чем MS SQL. Но потом, обнаружилось, что Postgresql не хуже чем, MS SQL просто есть различия в архитектуре. Точно так же как Мерседес не хуже чем БМВ, просто это разные автомобили. Я начинаю путаться в вашей позиции. Вы говорите сначала одно, потом другое....

..... Изначально понятно, что перенос кода под другую платформу всегда чреват как минимум большим количеством недочетов и ошибок, а как максимум - проблемами, ограничивающими функционал. И если бы так было, то перенос кода с Postgress под MS SQL вполне мог вызвать какие-то свои проблемы. Что вы здесь нашли удивительного или компрометирующего?

Т.е. вы все таки признаете, что проблема будет не в том, что Postgresql хуже MS SQL, а в том, что это другая СУБД и переход 1С на эту СУБД требует переделки кода? Мне очень трудно понять ваш ход мысли, вы часто "меняете показания", часто говорите взаимоисключающие вещи....