svcoder
Поверьте, люди серьезно занимающиеся разработкой в 1С не ведут регламентированный учет в той же базе.

Поверьте, мне очень редко встречались люди, серьезно занимающиеся разработкой в 1С. Чаще встречались люди, которые либо занимаются в основном борьбой с тормозами 1С, либо после которых проще выбросить конфу, чем продолжать ее "доработку". Да, если основной движек на Торговле, то бухучет ведут в отдельных бухгалтериях, но как Вам ЧЕТЫРЕ регистра взаиморасчетов в ОДНОЙ торговле? Я не умею так проектировать БД. И я не могу прям сразу выбросить эти регистры, так как я уже пятый, кто пытается в ней разобраться... Мне проще было написать вьюху по документам, сделать триггер, который изменяет конечные остатки, обернуть все это в класс на 1с++ и начать методично выискивать в конфе и большой горе ert-шек, где используются данные из этих регистров и переводить их на использование своего класса. Что такое "проведение" - переписать данные из таблицы документа в таблицу регистра по заданному алгоритму и пересчитать итоги. Это нельзя сделать в хранимке? А на клиенте разве нельзя сделать тот же компилятор ОбработкаПроведения() не во внутренний код интерпретатора 1С, а сразу в t-sql? Но сдургой стороны - а зачем вообще нужно "проведение"? если туже самую информацию можно получить по данным в самих документах?.. Ну да бог с ней, с 1С.

Я хотел сказать, что "самописка" начинается не только с чистого листа, но и с изменения какой-то уже развернутой ИС. В которой не устраивает либо реализация БП, либо быстродействие\удобство, либо отсутствующий (но необходимый или желательный) функционал. Типовые решения хороши для старта фирмы, Самописка "с нуля" хороши для фирмы, у которой уже сформировались собственые уникальные БП и есть силы\время\ресурсы доводить реализацию собственных БП в собственной ИС. В промежутке - чаще начинается ковыряние в "стартовой платформе" под мелкие запросы типа "а вот бы мне отчетик, который...". В силу дешевизны 1С именно она чаще всего и является стартовой. Получается что для "молодых, но быстроразвивающихся" фирм нету готового инструмента для быстрой разработки и модификации ИС. Либо 1С, либо Ax\Nav\Sap и т.д. Я имею ввиду только упр.учет. Вернее то, что можно назвать "Типовой упр.учет". У бухгалтерий выбор гораздо богаче в силу очень сильной регламентированности, и количество запросов на изменения без изменения в БУ\НУ - минимальны.

svcoder
Ну конечно, зачем что то разработывать, лучше подождать когда другие разработают, лет эдак через дцать. Может вам нужно научиться проектировать ИС, если сейчас все ваши изменения являются прикрутками и подлатками?

Мои изменения в виде прикруток и заплаток связаны с тем, что "нам уже сейчас надо работать". И я считаю, что проектирование ИС начинается с описания БП. Которые тоже еще нужно уметь описать. На мой взгляд основная задача сейчас от ИТ именно оптимизация бизнес-процессов. Именно там находятся основные тормоза... Соптимизировали ИС на напроведение 100 документов в день, вместо 10-ти, еще лучше если 1000... Но склад как отгружал 20-ть, так и отгружает и никакого эффективного выхлопа для бизнеса в целом наша оптимизация не принесла...

svcoder
переведите термин "спрямление запросов", плс.

замена "запросов 1С" на "запросы t-sql", например. Формирование полностью готовых наборов данных для отчетов на стороне сервера, вместо построчной обработки всех нужных таблиц на стороне клиента. ToySQL предлагает уже готовые переработанные конфы. Но ведь основных тормозов и они не лечат. Потому что основные тормоза не в скорости доступа к данным, а в неоптимальной системе хранении данных в 1С и очень больших накладных расходах на "проведение" документов силами клиента.
svcoder
Чем вам не нравиться структура БД в 1С?

А в 1С есть структура БД ? как ее посмотреть? такой популярный инструмент, как visio вытаскивает из базы 1С лишь набор абсолютно несвязанных таблиц. Никакой структуры. Может я где-то в конфигураторе упустил меню "структура БД"? Тоже вроде нету. Как может не нравиться то, чего не существует?

svcoder
Самый простое решение. Иметь несколько разработчиков и как можно больше внимания уделить проектированию и документированию.

Вы представьте сколько это будет стоить для конторы с 20-ю пользователями? Обычно фирмы орагнизовывают с несколько более другими целями, чем написание собственой ИС с полным комплектом проектой и пользовательской документации. Ну и опять не удержусь - ткните в соотношение 1С-франчей, которые ведут техническую и пользовательскую документацию по "доработкам в рамках договора" и те, которые нет? Я понимаю, что регионы разные, у нас большинство технической документации - в головах программеров. "Вася заболел, кто поеедет к клиенту <имярек>? кто помнит, что там Вася последний раз делал?" - и это франч, который обслуживает достаточно крупных клиентов.

Антиофтопик. :)
А никто не писал\пишет "самописку" типа "компилятора БП"? :) Ведь собственно что есть упр.учет? Описание бизнес-процессов до уровня документов и операций. Признаков состояния документов и элементов, изменяемых в операциях. Если описание БП детализировать до "...оператор заполняет документ ЗаявкаПокупателя, в котором заполняет <поля документа>. Если <Срок оплаты=По факту> и <вариант доставки=заявка целиком> и <наличие на складе>=количество> - оформялется документ РасходнаяНакладная... " Потом нажали кнопку "compile" и... получили систему учета. :)

svcoder
Начинаем урок:
http://en.wikipedia.org/wiki/Client-server

Продолжаем. Буквально следующий абзац - "Each instance of the client software can send data requests to one or more connected servers. In turn, the servers can accept these requests, process them , and return the requested information to the client". А не только "to share files and resources"... То есть не "вся логика находится на клиенте", а Клиент отправляет запрос, и получает в ответ обработанные данные. Как можно обработать данные без применения логики?

svcoder
Теперь представим себе обычную логику: определение просроченной дебиторской задолженности по группе контрагентов имея таблицы текущей задолженности, оплат и отгрузок.
Я хочу посмотреть, как вы будете это реализовывать на SQL? А если сложность задачи выше, и используется ООП для организации логики?

"таблицы текущей задолженности, оплат и отгрузок" - формируются например вызовом ссоотв. хранимки из триггеров на таблицах документов, изменяющих текущие задолженность, оплату и отгрузку. Вместо многостраничного ОбработкаПроведения() на клиенте получаем вызов на клиенте
ODBCRecordset.Выполнить(Шаблон("update table РасходнаяНакладная set Проведен=1 where IDDOC=[ТекущийДокумент()]));
что приведет к срабатыванию триггера на обновляемой таблице и вызова соответствующей хранимки на языке t-sql\pl-sql. Думаете язык t-sql\pl-sql недостаточно хорош для обработки данных?
Бизнес-логика не хранится в таблицах или коде. Бизнес-логика только говорит, как должно пройти изменение данных при определеных начальных данных и к какому результату оно должно привести. Реализовать бизнес-логику можно на любом языке программирования, в том числе и на t-sql\pl-sql\pg-sql\xxx-sql и на ООП - так или иначе бизнес-логика - программа изменения данных. А вот манипуляциями данными пускай уж лучше занимается специализированный сервер обработки данных, тем более что и до данных ему гораздо ближе.

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

svcoderИмеется ввиду что существует несколько серверов БД в сети и одна транзакция может распространиться на несколько серверов. А за слово requested information вообще нельзя цепляться.
Я к тому, что двух-звенка это не хранение данных на сервере и обработка их на клиенте, а, можно сказать, наоборот - хранение и обработка данных на сервере по запросу клиента. Чем тоньше клиент и чем больше сервер занят обработкой - тем более это похоже на "клиент-сервер".

Егоров Александр
Но если это более-менее сложная логика то использовать для этих целей SQL просто извращение.
более-менее сложная логика, на языке 1С даже большее извращение, чем на языке t-sql. Ибо язык 1С точно также предназначен для манипуляции данными (через использование готовых конструкций типа справочник\документ\операция\регистр), как и t-sql (через использование готовых конструкций table\view\procedure\trigger), но более убог по сравнению с современными ЯВУ, в т.ч. та самая java, на которую Вы не можете использовать в 1С, а разработчики на Oracle используют java в том числе и для создания расширенных процедур, исполняемых опять-таки на сервере.

Может перейдем тогда в форум по 1С, раз уж мы так сильно за нее уцепились?

svcoder
Раскройте тему о накладных расходах. Особенно если все стандартные блокировки 1С очищены и используется блокировка sp_getapplock.


Продолжение здесь

svcoder Егоров Александр
Вы представьте сколько это будет стоить для конторы с 20-ю пользователями? Обычно фирмы орагнизовывают с несколько более другими целями, чем написание собственой ИС с полным комплектом проектой и пользовательской документации.

Вот именно для таких фирм и существуют типовые конфигурации и франчи.

Типовая конфигурация не устраивает функционалом, франчи начинают доработку функционала, но постепенно становится ясно, что с франчами не устраивает отношением цена\\качество. Берут на работу своего прогрммера. Он начинает добавлять функционал, натыкается на падение производительности и вынужден вместо расширения бизнес-логики заниматься оптимизацией сначала того, что уже есть, потом того, что создается нового, либо тупо наращивать железо, что для маленькой компании тоже не всегда легко. Понатыкавшись на ограничения текущей платформы - начинаем оглядываться в поисках чего-то более другого - натыкаемся на цены и отсутствие грамотных внедренцев в регионе (и соотв. на цены внедрения), думаем... думаем... начинаем делать некие "примочки" на более дургих, обычно универсальных ЯП. "примочки" со временем вырастают в большой и неуправляемый клубок, становится ясно, что дальше так нельзя... Начинаем сравнивать стоимость собственной разработки на основе уже сделанных примочек, сравниваем стоимость коробок\\возможности платформ\\стоимости внедрений\\стоимости доработок... и приходим к выводу взять еще программеров, и "писать самим с нуля". Как только поток изменений в одной фирме становится выше стоимости собственного программера - франчи тут же отваливаются...

svcoder
То, о чем вы говорите можно сделать, но не является нормальным использованием механизма sql сервера. Для этих целей сейчас используются сервера приложений.

Это тема отдельной священной войны - "можно ли считать современные sql-сервера как сервер-приложений и сервер-бд в одном флаконе" и "так ли хороша трех-звенная архитектура, как о ней мечаталось?". Зачем городить сервер приложений (усложняя и удорожая стоимость ИС), если можно обойтись без него?

svcoder
Почему вы считаете что логика это куча операторов ВыбратьЭлементы(), ПолучитьЭлемент(),Записать(). А между ними что? Какой аналог есть в языке SQL для ИндексированныхТаблиц или в крайнем случае ТаблицыЗначений? Какой есть аналог понятия "модуль", в котором можно написать несколько процедур и функций. Какой есть аналог понятия класс из 1С++?
Не приплетайте яву, которая может выполнятся на сервере oracle, вы говорили именно о логике на языке SQL (или T-SQL, или PL-SQL).
Вопрос о выполнении java-программ на сервере вместо java-программ на клиенте совсем другой.

Я считаю, что результатом реализации бизнес-логики в ИС всегда является какое-либо манипулирование данными, составляющими основу это ИС. Манипуляцию данными лучше проводить инструментами, которые к этому более приспособлены. До тех пор, пока манипуляция данных строго формализована - весь это слой можно убирать на sql-сервер. Конструкции типа ИндексированнаяТаблица, ТаблицаЗначений, СписокЗначений в любом sql-сервере это table. Поставите на нее индексы - будет indexed table. "Модуль" - это и есть procedure\function\trigger.
Давайте не так, Давайте так - какую логику вы реализовываете в ОбработкеПроведения, не делая ни выборки данных из БД, ни записи данных в БД?
svcoder
Я рассматриваю 1С как обычную 2-х уровневую программу на visual basic, которая записывает данные на SQL Server с помощью специальных классов, и считывает через прямые sql запросы. Ну и метаданные хранит в специальном формате.

Ну что я могу сказать? в рамках топика 1Ска может выступать и как "коробка" - при наличии нетронутой типовой конфигурации, и как "самописка" - если на 1С переделанная типовая или собственная конфа. В качестве использования 1С в "самописке" цитирую сам себя: "выбранной автором самописки по своим собственным критериям". Если вас устраивает 1С - ради бога. Меня же она не устраивает, и боюсь, друг другу мы ничего доказать не сможем... :(

sopromat
Вы когда нибудь занимались подбором кадров? Кодера грамотного проблематично найти. А Вы предлагаете легко найти разработчика и внедренца в одном лице.

Найти грамотных специалистов так же трудно и среди поставщиков, внедренцев и консультантов готовых продуктов. В том числе и продуктов микрософт. :) И в отличии от Васи и Димы они требуют более дорогостоящей мотивации со стороны компании, решившей приобрести и внедрить коробку, особенно при необходимости дальнейшей адаптации коробки...

anonimouse Алексей Е. Megabyte
Вопрос к 1С-никам: в 1С можно управлять планом запроса напрямую? Это не с целью подколоть, просто хочу узнать!
Нет. Даже нельзя напрямую послать SQL запрос.
А если я на двух пальцах покажу как это делается??
в 7.7 или 8.х ?

beluginТо есть чем специфичней работа, тем лучше ее сделает Вася, а чем более тиражируема работа, тем лучше ее сделает MS.
собсно это и является темой топика - можно ли, и если можно, то как определить специфичность работы, чтобы выбрать кого приглашать MS или Васю. Судя по статистике внедрений "крупных erp" и количеству собственных программистов в фирмах, купивших коробочную 1С - пока побеждают Васи. :)