Здравствуйте, <Аноним>, Вы писали:


А>Но вот мне на работе так её хвалят. что мне это надоело до смерти. Говорят: "Вот ведь, работает! Ну и что, что некрасиво. Зато работает. И дальше будем заказывать софт на 1с. Это стандарт в области бухгалтерского ПО! Не можем долго ждать, пока софт будет на языках писать. Безопасность? Ну она же реализуется не только програмными средствами и т.д." Ну и что на такое возразить?

Ты знаешь, а они ведь правы — кто платит, тот и заказывает музыку. И я бы серъезно задумался почему 1С пользуется такой популярностью, а "крютые" самописные программы нет.

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

AVK>Ты знаешь, а они ведь правы — кто платит, тот и заказывает музыку. И я бы серъезно задумался почему 1С пользуется такой популярностью, а "крютые" самописные программы нет.

Вот я и задумался! Это означает голодную смерть или переучивание для большинства программеров?

Здравствуйте, Serginio1, Вы писали:
>А 2 ГБ это много??? Работают и с поболее большими базами. ДБФ+TSE прекрасно рулят. Да без транзакций, но гибкость и скорость важнее. При этом делают резервное копирование поверх рабочей БД и при возникновении сбоя восстанавливают с тестированием и обновлением ИБ. Но сбои в основном бывают при сетевом подключении при вырубании клиентского компьютера когда он может записывать грязь.

Ну что ты мне сказки рассказываешь... Какая гибкость? Какая скорость? Это когда все 2ГБ*кол-во юзеров по сети одновременно копируются? Это и есть в твоём представлении гибкость и скорость? "сбои в основном бывают при сетевом подключении " — ага, и только... жаль только, что по несколько раз на дню и не у одного юзера...Или у тебя один пользователь на такой базе локально висит и ты на этом опыте такие выводы строишь?

Здравствуйте, <Аноним>, Вы писали:

AVK>>Ты знаешь, а они ведь правы — кто платит, тот и заказывает музыку. И я бы серъезно задумался почему 1С пользуется такой популярностью, а "крютые" самописные программы нет.

А>Вот я и задумался! Это означает голодную смерть или переучивание для большинства программеров?

Нет, это означает что вместо супер оптимизаций и алгоритмов и навороченных интерфейсов думать надо о полезности софта клиенту.

Здравствуйте, <Аноним>, Вы писали:

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

AVK>>Ты знаешь, а они ведь правы — кто платит, тот и заказывает музыку. И я бы серъезно задумался почему 1С пользуется такой популярностью, а "крютые" самописные программы нет.

А>Вот я и задумался! Это означает голодную смерть или переучивание для большинства программеров?

А>Здравствуйте, Serginio1, Вы писали:
>>А 2 ГБ это много??? Работают и с поболее большими базами. ДБФ+TSE прекрасно рулят. Да без транзакций, но гибкость и скорость важнее. При этом делают резервное копирование поверх рабочей БД и при возникновении сбоя восстанавливают с тестированием и обновлением ИБ. Но сбои в основном бывают при сетевом подключении при вырубании клиентского компьютера когда он может записывать грязь.

А>Ну что ты мне сказки рассказываешь... Какая гибкость? Какая скорость? Это когда все 2ГБ*кол-во юзеров по сети одновременно копируются? Это и есть в твоём представлении гибкость и скорость? "сбои в основном бывают при сетевом подключении " — ага, и только... жаль только, что по несколько раз на дню и не у одного юзера...Или у тебя один пользователь на такой базе локально висит и ты на этом опыте такие выводы строишь?
А ты знаешь, что такое TSE ???? Может Citryx тебе что то говорит????? При отключении проблемами с сетью сессии остаются и при новом подключении оказываешься там где был. Очень активно применяют TSE и для SQL когда для болшего использования быстрого канала и максимально использование более мощного сервера чем пользовательские машины которые сильно тормозят при транзакциях с клиента.

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

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

G>>Важнейшее преимущество 1С — вместе со средой разработки и рантаймом ты получаешь Бухгалтерию + Торговлю + Склад в исходниках. Отлаженную, соответствующую законодательству.
VVP>Вот только не надо киздить про отлаженность, хАрАшо! От слова "лажа" происходит та отлАженность.
G>>Платформа очень сильно заточена под складские и бухгалтерские задачи, что дает выигрыш.
VVP>Ага, особенно под складские нужды заточена, вот блин зашибись ее заточили!
G>>В результате у нас никто не любил 1С, но все его использовали везде где возможно, иногда как составную часть большей системы, работающей под MS SQL/VB6. При грамотном использовании 1С позволяет выигрывать тендеры по цене, и при этом серьезно снизить себестоимость разработки, при прочих равных. Главное — понять, где 1С ни в коем случае использовать нельзя. Иначе можно попасть по крупному. Но при знании платформы это не составляет труда.
VVP>Как налоговый калькулятор ее можно использовать, даже нужно. Но не более. Любой оперативный учет в компании с сотней рабочих мест под 1С-ом становиться невыносимым, это еще мягко сказано...

У 1с есть своя достаточно большая ниша и в этой нише она действительно рулит. А попытки использовать 1с на крупных прядприятях — это откровенное проявляение безгамотности ИТ отдела. Сама архитектура программы не расчитана на это. А TS это не решение проблемы, а так...

А с точки зрения качества программмы, всем бы так писать 7.7 уже используется несколько лет без обновлений

Здравствуйте, <Аноним>, Вы писали:



А>У 1с есть своя достаточно большая ниша и в этой нише она действительно рулит. А попытки использовать 1с на крупных прядприятях — это откровенное проявляение безгамотности ИТ отдела. Сама архитектура программы не расчитана на это. А TS это не решение проблемы, а так...

А>А с точки зрения качества программмы, всем бы так писать 7.7 уже используется несколько лет без обновлений
Только существующий релиз 21, у 7.5 был за 30. Брака очень много как в самой платформе так и в конфигурациях, но в конфигурациях хоть своими ручками быстро исправляешь а вот с платформой приходится писать код в обход багов. Помню еще в 7.0 столько было багов. Но с другой стороны, получил работающую конфигурацию с возможностью быстрой адаптации под свои нужды.
Обычно нормально фунуционирующая версия выходит через год после выхода версии. Вот и восьмерка сколько была на бетта тестировании все равно всех багов не удалили.

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

S> А ты знаешь, что такое TSE ????
Я знаю, что такое Terminal server. И не надо сыпать сокращениями. И что такое E?

S> При отключении проблемами с сетью сессии остаются и при новом подключении S>оказываешься там где был.
"отключении проблемами" — интересный оборот речи

S>Очень активно применяют TSE и для SQL когда для болшего использования быстрого канала S>и максимально использование более мощного сервера чем пользовательские машины которые S>сильно тормозят при транзакциях с клиента.

Ты сам то понял, что сказал...

А сколько по твоему нужно памяти на одного клиента на компе с TS? Вот у нас получилось по 80-100Mb (для комфортной работы)

Здравствуйте, <Аноним>, Вы писали:

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

S>> А ты знаешь, что такое TSE ????
А>Я знаю, что такое Terminal server. И не надо сыпать сокращениями. И что такое E?
Edition. Вообжето это общепринятая абревиатура.
S>> При отключении проблемами с сетью сессии остаются и при новом подключении S>оказываешься там где был.
А>"отключении проблемами" — интересный оборот речи
Очень старался, но не получилось.
S>>Очень активно применяют TSE и для SQL когда для болшего использования быстрого канала S>и максимально использование более мощного сервера чем пользовательские машины которые S>сильно тормозят при транзакциях с клиента.

А>Ты сам то понял, что сказал...
Что не понятно???? То есть TSE c SQL не применяют ????
А>А сколько по твоему нужно памяти на одного клиента на компе с TS? Вот у нас получилось по 80-100Mb (для комфортной работы)
Чем больше тем лучше и процессоров побольше и еще добавить на "активно работающего клиента".

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

А>>Ты сам то понял, что сказал...
S> Что не понятно???? То есть TSE c SQL не применяют ????
Да нет, не то. Ты бы падежи соблюдал и логические связи в предложении.

А>>А сколько по твоему нужно памяти на одного клиента на компе с TS? Вот у нас получилось по 80-100Mb (для комфортной работы)
S> Чем больше тем лучше и процессоров побольше и еще добавить на "активно работающего клиента".

А если клиентов будет 30-40 + MS SQL, то сколько же памяти нужно? Даже подумать страшно... А ты говоришь 1С — хорошо.

Здравствуйте, <Аноним>, Вы писали:

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

А>>>Ты сам то понял, что сказал...
S>> Что не понятно???? То есть TSE c SQL не применяют ????
А>Да нет, не то. Ты бы падежи соблюдал и логические связи в предложении.

А>>>А сколько по твоему нужно памяти на одного клиента на компе с TS? Вот у нас получилось по 80-100Mb (для комфортной работы)
S>> Чем больше тем лучше и процессоров побольше и еще добавить на "активно работающего клиента".

А>А если клиентов будет 30-40 + MS SQL, то сколько же памяти нужно? Даже подумать страшно... А ты говоришь 1С — хорошо.
Обычно 2 сервера. Первый на терминальные сессии второй для SQL с гигабитным каналом.
Я говорю, что для определенных задач 1С хорошо. Улучшить ее можно. Даже без SQL но на своей базе сделать Клиент — Сервер полностью на ООП. Если даже TSE+ДБФ устраивает большинство, то компилированный объектный код увеличивает скорость в 30 раз.
http://www.1c.hippo.ru/cgi-bin/predownl.cgi?id=2019. И скорости будут большие и ресурсы жрать по минимуму. Правда небольшой геморой с транзакциями, но все равно в большинстве проведение документов проходит последовательно, а при изменении данных транзакциями выделять новые страницы которые не быдут читаться другими транзакциями до завершения транзакции. Некий версионник только на уровне страниц а не записей.

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

А>>Я знаю, что такое Terminal server. И не надо сыпать сокращениями. И что такое E?
S> Edition. Вообжето это общепринятая абревиатура.

Это не общепринятая аббревиатура, а жаргон. Это TSE произошло от первой МСовской реализации — NT4 Terminal Server Edition. На данный момент текущим продуктам не соответствует.

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

S> Я говорю, что для определенных задач 1С хорошо. Улучшить ее можно. Даже без SQL но на своей базе сделать Клиент — Сервер полностью на ООП. Если даже TSE+ДБФ устраивает большинство, то компилированный объектный код увеличивает скорость в 30 раз.

Не кажется ли, что здесь речь уже практически не идет о движке 1С? И куда деваться от ненормализованности и довольно слабо (или почти не) связанных между собой таблиц, напр. таблиц с документами и регстров, куда пишется при "проведении" информация из этих самых документов?

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

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

А>>>Я знаю, что такое Terminal server. И не надо сыпать сокращениями. И что такое E?
S>> Edition. Вообжето это общепринятая абревиатура.

AVK>Это не общепринятая аббревиатура, а жаргон. Это TSE произошло от первой МСовской реализации — NT4 Terminal Server Edition. На данный момент текущим продуктам не соответствует.
Тады Цитрикс. Так или иначе его используют по верху TS и на других платформах самостоятельно. M$ терминалы дошли до уровня Цитрикс только в 2003 да и то не полностью. Да и TSE помоему купили у Цитрикса.

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

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

S>> Я говорю, что для определенных задач 1С хорошо. Улучшить ее можно. Даже без SQL но на своей базе сделать Клиент — Сервер полностью на ООП. Если даже TSE+ДБФ устраивает большинство, то компилированный объектный код увеличивает скорость в 30 раз.

A>Не кажется ли, что здесь речь уже практически не идет о движке 1С? И куда деваться от ненормализованности и довольно слабо (или почти не) связанных между собой таблиц, напр. таблиц с документами и регстров, куда пишется при "проведении" информация из этих самых документов?
Нормализация там нормальная. Вообще в регистрах есть поле IDDoc

Вот как выглядят таблицы остатков

    TOstatkiTovarovDvigRec=record
deleted:char;
IDDOC: array[0..8] of char;
LINENO: array[0..3] of char;
ACTNO: array[0..5] of char;
DEBKRED: char;
Firma: TIDField;//SP3603
Tovar: TIDField;//SP101
Sklad: TIDField;//SP100
OstatokTovara: array[0..15] of char;//SP102
FlagUcheta: array[0..1] of char;//SP1020
end;

TOstatkiTovarovOstRec=record
deleted:char;
Period:TDate1C;
Firma: TIDField;//SP3603
Tovar: TIDField;//SP101
Sklad: TIDField;//SP100
OstatokTovara: array[0..15] of char;//SP102
end;

И вообще на модели таблиц 1С очень лешко строится ООП модель.

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

AVK>>Это не общепринятая аббревиатура, а жаргон. Это TSE произошло от первой МСовской реализации — NT4 Terminal Server Edition. На данный момент текущим продуктам не соответствует.
S> Тады Цитрикс.

Что Цитрикс?

S> Так или иначе его используют по верху TS и на других платформах самостоятельно. M$ терминалы дошли до уровня Цитрикс только в 2003 да и то не полностью. Да и TSE помоему купили у Цитрикса.

Какое это имеет отношение к обзыванию Terminal Services TSE?

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

A>>Не кажется ли, что здесь речь уже практически не идет о движке 1С? И куда деваться от ненормализованности и довольно слабо (или почти не) связанных между собой таблиц, напр. таблиц с документами и регстров, куда пишется при "проведении" информация из этих самых документов?
S> Нормализация там нормальная. Вообще в регистрах есть поле IDDoc

Наверное, у меня какое-то неправильное представление о нормализации.

S> Вот как выглядят таблицы остатков

И что, по этим двум вышеописанным таблицам можно судить о нормализации всей 1С?

CREATE TABLE 1SBKTTL (
DATE    DATETIME
ACCID    CHAR(9)
CURRID    CHAR(9)
KIND    CHAR(1)
OBDT1    CHAR(15)
OBKT1    CHAR(15)
OBDT2    CHAR(15)
OBKT2    CHAR(15)
OBDT3    CHAR(15)
OBKT3    CHAR(9)
SD    CHAR(15)
FLAGS    LONG
VSC0    CHAR(4)
SC0    CHAR(13)
OSC0    LONG
VSC1    CHAR(4)
SC1    CHAR(13)
OSC1    LONG
VSC2    CHAR(4)
SC2    CHAR(13)
OSC2    LONG);

Это тоже структура нормализованной таблицы?

И еще. Что, информация о продаже (отраженной в строке "документа") физически хранится только как запись в таблице табличной части документа, или эта же самая информация КОПИРУЕТСЯ при "проведении" документа еще и в другие таблицы, напр. т.н. регистры? Это называется реляционностью и нормализацией? Неужели поле IDDOC в таблице регистров является "эмулятором" внешнего ключа а не для иных целей? И может постоянные еженочные "перепроведения" документов и являются следствием подобной "нормальной нормализации"?

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

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

A>>>Не кажется ли, что здесь речь уже практически не идет о движке 1С? И куда деваться от ненормализованности и довольно слабо (или почти не) связанных между собой таблиц, напр. таблиц с документами и регстров, куда пишется при "проведении" информация из этих самых документов?
S>> Нормализация там нормальная. Вообще в регистрах есть поле IDDoc

A>Наверное, у меня какое-то неправильное представление о нормализации.

S>> Вот как выглядят таблицы остатков

A>И что, по этим двум вышеописанным таблицам можно судить о нормализации всей 1С?

A>

A>CREATE TABLE 1SBKTTL (
A>DATE    DATETIME
A>ACCID    CHAR(9)
A>CURRID    CHAR(9)
A>KIND    CHAR(1)
A>OBDT1    CHAR(15)
A>OBKT1    CHAR(15)
A>OBDT2    CHAR(15)
A>OBKT2    CHAR(15)
A>OBDT3    CHAR(15)
A>OBKT3    CHAR(9)
A>SD    CHAR(15)
A>FLAGS    LONG
A>VSC0    CHAR(4)
A>SC0    CHAR(13)
A>OSC0    LONG
A>VSC1    CHAR(4)
A>SC1    CHAR(13)
A>OSC1    LONG
A>VSC2    CHAR(4)
A>SC2    CHAR(13)
A>OSC2    LONG);
A>

A>Это тоже структура нормализованной таблицы?

A>И еще. Что, информация о продаже (отраженной в строке "документа") физически хранится только как запись в таблице табличной части документа, или эта же самая информация КОПИРУЕТСЯ при "проведении" документа еще и в другие таблицы, напр. т.н. регистры? Это называется реляционностью и нормализацией? Неужели поле IDDOC в таблице регистров является "эмулятором" внешнего ключа а не для иных целей? И может постоянные еженочные "перепроведения" документов и являются следствием подобной "нормальной нормализации"?

То что ты привел называется поля с неопределенным типом. И это в реляционность не укладывается, по этому и существуют споры об ООБД и реляционных БД. По поводу регистров и документов то они решают разные задачи. Может быть множество документов воздействующих на один региср, так же как и один документ воздействует на множество регистров. В этом я с 1С солидарен, т.к. легко вычислить остатки на определенный документ и разделить информацию по регистрам и документам. Кстати это одна из сильных сторон 1С.
А перепроведения не зависят, т.к. Есть регистры Партии товаров LIFO FIFO итд. и если в документе что то меняется задним числом это отражается на регистрах. В других системах делается через сторно но это не всегда удобно а иногда приводит к огромным проблемам.
Не нравится 1С есть Парус,Навижн, Акзапта где все эти прелести есть. А вот желающих проводить документов задним числом очень много.
Если тебе не нравится заблокируй проведение задним числом и нкакиз перепроведений документов не будет.

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

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

AVK>>>Это не общепринятая аббревиатура, а жаргон. Это TSE произошло от первой МСовской реализации — NT4 Terminal Server Edition. На данный момент текущим продуктам не соответствует.
S>> Тады Цитрикс.

AVK>Что Цитрикс?

S>> Так или иначе его используют по верху TS и на других платформах самостоятельно. M$ терминалы дошли до уровня Цитрикс только в 2003 да и то не полностью. Да и TSE помоему купили у Цитрикса.

AVK>Какое это имеет отношение к обзыванию Terminal Services TSE?
Тады вместо TS применять Цитрикс т.к. он платформонезависимый и в основном работа идет через него (больше возможностей), а так как Terminal Services это купленный цитрикс то абревиатуру по работе с терминальными сессиями просто обозначать как "Цитрикс" и привести терминалогию к одному знаменателю.

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

A>>>>Не кажется ли, что здесь речь уже практически не идет о движке 1С? И куда деваться от ненормализованности и довольно слабо (или почти не) связанных между собой таблиц, напр. таблиц с документами и регстров, куда пишется при "проведении" информация из этих самых документов?

S>>> Нормализация там нормальная. Вообще в регистрах есть поле IDDoc

A>>Это тоже структура нормализованной таблицы?

[sorry, skipped]

A>>И еще. Что, информация о продаже (отраженной в строке "документа") физически хранится только как запись в таблице табличной части документа, или эта же самая информация КОПИРУЕТСЯ при "проведении" документа еще и в другие таблицы, напр. т.н. регистры? Это называется реляционностью и нормализацией? Неужели поле IDDOC в таблице регистров является "эмулятором" внешнего ключа а не для иных целей? И может постоянные еженочные "перепроведения" документов и являются следствием подобной "нормальной нормализации"?

S> То что ты привел называется поля с неопределенным типом. И это в реляционность не укладывается, по этому и существуют споры об ООБД и реляционных БД.

А при чем здесь споры об ООБД?

S> По поводу регистров и документов то они решают разные задачи.

А при чем здесь разные задачи? Я про реляционность, а ты?

S> Может быть множество документов воздействующих на один региср, так же как и один документ воздействует на множество регистров. В этом я с 1С солидарен, т.к. легко вычислить остатки на определенный документ и разделить информацию по регистрам и документам. Кстати это одна из сильных сторон 1С.

По-моему, это дело вкуса, о котором не спорят . Но существуют и другие способы релизации, о чем когда-то и говорил тебе VladD2, давая ссылку, напр. сюда

Автор(ы): Владислав Чистяков

.

S> А перепроведения не зависят, т.к. Есть регистры Партии товаров LIFO FIFO итд. и если в документе что то меняется задним числом это отражается на регистрах.

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

S> В других системах делается через сторно но это не всегда удобно а иногда приводит к огромным проблемам.
S> Не нравится 1С есть Парус,Навижн, Акзапта где все эти прелести есть. А вот желающих проводить документов задним числом очень много.
S> Если тебе не нравится заблокируй проведение задним числом и нкакиз перепроведений документов не будет.

Я заблокировал перепроведение документов задним числом, но *типовая* 1С плохо к этому приспособлена.

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



A>>>И еще. Что, информация о продаже (отраженной в строке "документа") физически хранится только как запись в таблице табличной части документа, или эта же самая информация КОПИРУЕТСЯ при "проведении" документа еще и в другие таблицы, напр. т.н. регистры? Это называется реляционностью и нормализацией? Неужели поле IDDOC в таблице регистров является "эмулятором" внешнего ключа а не для иных целей? И может постоянные еженочные "перепроведения" документов и являются следствием подобной "нормальной нормализации"?

S>> То что ты привел называется поля с неопределенным типом. И это в реляционность не укладывается, по этому и существуют споры об ООБД и реляционных БД.

A>А при чем здесь споры об ООБД?

S>> По поводу регистров и документов то они решают разные задачи.

A>А при чем здесь разные задачи? Я про реляционность, а ты?

S>> Может быть множество документов воздействующих на один региср, так же как и один документ воздействует на множество регистров. В этом я с 1С солидарен, т.к. легко вычислить остатки на определенный документ и разделить информацию по регистрам и документам. Кстати это одна из сильных сторон 1С.

A>По-моему, это дело вкуса, о котором не спорят . Но существуют и другие способы релизации, о чем когда-то и говорил тебе VladD2, давая ссылку, напр. сюда

Автор(ы): Владислав Чистяков

.
Все не так просто как кажется. Иначе бы не было проблем у Паруса с бухгалтерией. Я все время привожу пример но никто не слушает.
Если проводка в корой есть поля для субконто. Но субконто у каждого счета имеют свой тип. Это укладывается в нормализацию но не в Sql так как поле имеет вид
Subconto = packed record
IDType:Integer;
ID:Integer;
end;
В 1С это запись представлена строкой.
Но не укладывается в SQL. Поэтому на ДБФ неопределенные типы разруливаются легко, а на SQL только с клиента.
S>> А перепроведения не зависят, т.к. Есть регистры Партии товаров LIFO FIFO итд. и если в документе что то меняется задним числом это отражается на регистрах.

A>В этом месте, кажется, ты описываешь суть парадоксов вставки, обновления в ненормализованных базах данных.
Это парадоксы учета и проведения задним числом. Обычно что бы не перепроводить все документы, делаю корректировку, с последующим
запрещением изменения этих документов.

S>> В других системах делается через сторно но это не всегда удобно а иногда приводит к огромным проблемам.
S>> Не нравится 1С есть Парус,Навижн, Акзапта где все эти прелести есть. А вот желающих проводить документов задним числом очень много.
S>> Если тебе не нравится заблокируй проведение задним числом и нкакиз перепроведений документов не будет.

A>Я заблокировал перепроведение документов задним числом, но *типовая* 1С плохо к этому приспособлена.
Все в твоих руках для каждого документа проверяй его актуальность и если что не так СтатусВозврата(0) или только просмотр, только проблем будет для юзеров больше. А чем не нравятся Парус,Навижн, Акзапта ????