Здравствуйте, neFFy, Вы писали:


FF>ищу я, ищу : ) на рсдн-е же видел. =\ и ссылка была на сайт 1С.. =\ только там была не вся 1С-ка, а какой то ее кусок.. или я не разбираюсь в них)
FF>пока, по-умолчанию, я соврал.. =\
вроде терминалка была

Здравствуйте, Mamut, Вы писали:

M>>>Я во многих лавках видел большие чудеса, вытворяемые на ВБСкрипте и редакторах форм. Все это надо еще переписать под OpenOffice. Кто займется? Кто поставит ЕГАИС? 1С? И т.д и т.п.?

FF>>1С под линух уже есть..
FF>>но мы ж говорим о гос.секторе.. при чем тут "многие лавки" ?.

M>Ладно. Система учета поступающих налогов. Или там система учета регистрирующихся в Москве приезжих. Тот же ЕГАИС (похожая система есть у таможенников, например)

У таможенников большая часть системы сделана на веб-интерфейсе, остальное почти все запустится в DosBox`е, а из тех 3-х программ которые я видел у них под Виндовс, одна без проблем пошла под wine, две другие просто поленился качать с сайта SoftLand`a. Так что таможня на линукс перейти может без каких либо проблем прямо сейчас.

Здравствуйте, neFFy, Вы писали:
FF>ищу я, ищу : ) на рсдн-е же видел. =\ и ссылка была на сайт 1С.. =\ только там была не вся 1С-ка, а какой то ее кусок.. или я не разбираюсь в них)
FF>пока, по-умолчанию, я соврал.. =\
Под линуксом может работать Postgress, который 1С 8.1 может использовать в качестве хранилища данных.
Сервер 1С-Предприятие реализован как COM+ приложение, со всеми вытекающими последствиями.

Здравствуйте, alexqc, Вы писали:

A>В исходном посте было написано "1С под линух уже есть.."
A>Вот именно енто самое "1С фор Линух" (ну или аналог, но под *никс) я и хочу увидеть.
A>Интересно, neFFy ответит?

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

Автор: Sheridan
Дата: 28.12.06

Здравствуйте, dmur, Вы писали:

FF>>ищу я, ищу : ) на рсдн-е же видел. =\ и ссылка была на сайт 1С.. =\ только там была не вся 1С-ка, а какой то ее кусок.. или я не разбираюсь в них)
FF>>пока, по-умолчанию, я соврал.. =\
D>Под линуксом может работать Postgress, который 1С 8.1 может использовать в качестве хранилища данных.
D>Сервер 1С-Предприятие реализован как COM+ приложение, со всеми вытекающими последствиями.

я не знаю через что они это сделали, но они это сделали
здесь

Автор: Sheridan
Дата: 28.12.06

Здравствуйте, neFFy, Вы писали:
FF>я не знаю через что они это сделали, но они это сделали
Почитал, забавно, что кластер под линуксом не сможет работать с MS SQL.

Здравствуйте, dmur, Вы писали:

FF>>я не знаю через что они это сделали, но они это сделали
D>Почитал, забавно, что кластер под линуксом не сможет работать с MS SQL.
Всмысле? ты ппро сервак 1с? Так он с постгресом работает, а постгрес имхо будет получше микрософтовской подделки...

Здравствуйте, Sheridan, Вы писали:
S>Всмысле? ты ппро сервак 1с? Так он с постгресом работает, а постгрес имхо будет получше микрософтовской подделки...
Посмотрим.
Не видел сравнение постгресса с MSSQL или Oracle на больших объемах данных?

Здравствуйте, dmur, Вы писали:

D>Не видел сравнение постгресса с MSSQL или Oracle на больших объемах данных?
неа... Увидиш — свистни.

Здравствуйте, Sheridan, Вы писали:

D>>Не видел сравнение постгресса с MSSQL или Oracle на больших объемах данных?
S>неа... Увидиш — свистни.

А чего его смотреть? Я вот своими глазами видел, как загибался постгресс на БД размером всего-то 20 гигов...

Здравствуйте, LuciferArh, Вы писали:
LA>А чего его смотреть? Я вот своими глазами видел, как загибался постгресс на БД размером всего-то 20 гигов...
Нагнуть можно и Oracle, одним простым запросом.

LuciferArh wrote:
> А чего его смотреть? Я вот своими глазами видел, как загибался постгресс
> на БД размером всего-то 20 гигов...
Дак это элементарно на любой базе делается — берем и делаем декартово
произведение пары больших таблиц где-нибудь из хранимки, а потом
пытаемся что-нибудь сделать с результатом.

Skype, например, использует Postgres для хранения базы пользователей. Я
у себя использую Postgres тоже очень успешно. Причем такие фичи, как
транзакционный DDL, даже не снились всяким Оракулам.

Здравствуйте, dmur, Вы писали:

D>Нагнуть можно и Oracle, одним простым запросом.

Легко!.. Есть у меня такие запросики... В наследство достались... БД вроде бы скромная по размеру, всего что-то в районе 600 гигов. Но запросом нагибается так, что будь здоров! Восьмипроцессорный сервак уходит в даун минут на 15...

Здравствуйте, Cyberax, Вы писали:
C>Я у себя использую Postgres тоже очень успешно. Причем такие фичи, как
C>транзакционный DDL, даже не снились всяким Оракулам.
Что имеется в виду под транзакционным DDL?
Вот такое что ли

begin tran
create table test (id int identity primary key)
rollback tran

? MS SQL как минимум 2000 и выше; насчет семерки я просто не уверен.

Sinclair wrote:
> begin tran
> create table test (id int identity primary key)
> rollback tran
> ? MS SQL как минимум 2000 и выше; насчет семерки я просто не уверен.
Ты заметь, что я написал "Оракулам"

В Оракле DDLи автоматически коммитят текущую транзакцию

Здравствуйте, Cyberax, Вы писали:

C>В Оракле DDLи автоматически коммитят текущую транзакцию

А это кому-нибудь мешает? Мне — так нисколько. Я даже рад, ибо юзеры (в зависимости от "правильности" клиента) будут работать уже с новыми метаданными, а не с каким-то "устаревшим хламом".

Здравствуйте, LuciferArh, Вы писали:

C>>В Оракле DDLи автоматически коммитят текущую транзакцию

LA>А это кому-нибудь мешает? Мне — так нисколько. Я даже рад, ибо юзеры (в зависимости от "правильности" клиента) будут работать уже с новыми метаданными, а не с каким-то "устаревшим хламом".

Мешает. Например в случае динамически генерируемой структуры базы, когда под каждую категорию каких-либо данных генерируется таблица соответствующей структуры (и обслуживающие структурно-зависимые хранимые процедуры). При автокоммите DDL все эти операции оказываются разнесенными по разным транзакциям:

insert into lists (...);
insert into list_columns (...), (...), (...), ...;

create table listN (...);

create procedure listN_proc1 ...;
create procedure listN_proc2 ...;
...

LuciferArh wrote:
> C>В Оракле DDLи автоматически коммитят текущую транзакцию
> А это кому-нибудь мешает? Мне — так нисколько. Я даже рад, ибо юзеры (в
> зависимости от "правильности" клиента) будут работать уже с новыми
> метаданными, а не с каким-то "устаревшим хламом".
Мне мешает. В частности, при репликации изменений базы данных при ошибке
в середине скрипта мы получим базу в непонятном состоянии. В Postgres'е
все корректно будет откачено.

Здравствуйте, Cyberax, Вы писали:

C>Мне мешает. В частности, при репликации изменений базы данных при ошибке
C>в середине скрипта мы получим базу в непонятном состоянии. В Postgres'е
C>все корректно будет откачено.

При репликации метаданных или собственно данных? Если второе, то никто не мешает поставить SAVEPOINT и в случае ошибки сделать ROLLBACK. А реплицировать метаданные, да еще на рабочей БД и без предварительного бэкапа — это преступление.

LuciferArh wrote:
> При репликации метаданных или собственно данных? Если второе, то никто
> не мешает поставить SAVEPOINT и в случае ошибки сделать ROLLBACK. А
> реплицировать метаданные, да еще на рабочей БД и без предварительного
> бэкапа — это преступление.
У меня делается распределенное приложение, у клиентов будет стоять своя
вычислительная нода со своей базой. Значит и клиентам нужно будет как-то
реплицировать изменения, и хочется это делать автоматически.

В идеале при апгрейде никаких проблем возникнуть не должно, но в
реальности "shit happens", так что хотелось бы иметь уверенность, что
база не останется в непонятном состоянии.