Двухзвенка vs трехзвенка #519873

Чем двухзвенка лучше/хуже трехвенки в РСУБД?

собственно не обязательно про 1С, этакий аргументированный холивар

нельзя сравнивать не сравниваемое

обоснуй, есть куча задач которые можно решить обоими методами

Приведи хоть один пример такой задачи

да вот хоть взять любую учетную систему, подобную УТ

А ну да согласен. Тогда

1-й тип задач (совсем не жрут ресурсы) Достаточно двузвенки и притом проще. 2-й тип задач (самый распрстраненный) Желательно трезвенка, но можно и на двузвенке (всё упирается в бабло) 3-й тип задач (ресурсоёмкие) Двузвенка не тянет. ИМХО как-то так.

почему двузвенка не тянет?

А логику и процессы разные считать Пушкин будет?

Например как мне кажется клиенты слабые (например веб клиенты) а на скуле больно то бизнес-логику не реализуешь.

Я о том что такое-же быстродействие на двузвенной архитектуре для такого типа задач не то что бы невозможно, а что выйдет несоизмеримо дороже.

Бузнес-логика кокраз на скуле то и должна в основном в виде хранимок реализовываться. Так что тут явно холиварный момент :)

Ну да особенно давай сделайка расчет себестоимости с использование системы типа РАУЗ на хранимке. Я конечно может не знаток СКУля, но пля это явно на порядок геморойней чем на коде.

SQL сервер это да, но многие субд уже теперь позволяют писать код на ООП: java, C#

кстати почему еще никто не написал транслятора из чегото типа C# в SQL

"многие субд уже теперь позволяют писать код на ООП: java, C#" Да ну??? А ну перечисли то "множество СУБД" которое "работает" на C# Ну и если не сложно, напомни плз кто ещё кроме Oracle "работает" на джаве?

3-х звенку можно реализовать как в 8.0. Через тормозной и глючный com+ и единственную "дырку" на вход без распределения нагрузки... накой оно тогда

Будь первым, напиши. Может даже премию вручат. Кому-нибудь...

про безопасность кстати никто не сказал еще...

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

В некоторых СУБД возможно использование хранимых процедур, написанных на любом языке программирования, способном создавать независимые исполняемые файлы, например, на C++ или Delphi. В терминологии Microsoft SQL Server такие процедуры называются расширенными хранимыми процедурами и являются просто функциями, содержащимися в Win32-DLL. А, например, в Interbase и Firebird для функций, вызываемых из DLL/SO, определено другое название — UDF (User Defined Function). В MS SQL 2005 появилась возможность написания хранимых процедур на любом языке .NET, а от расширенных хранимых процедур в будущем планируется отказаться. СУБД Oracle, в свою очередь, допускает написание хранимых процедур на языке Java. В IBM DB2 написание хранимых процедур и функций на обычных языках программирования является традиционным способом, поддерживаемым с самого начала, а процедурное расширение SQL было добавлено в эту СУБД только в достаточно поздних версиях, после его включения в стандарт ANSI.

расскажи

"а процедурное расширение SQL было добавлено в эту СУБД только в достаточно поздних версиях, после его включения в стандарт ANSI." (задумчиво) э-э-э-э... А это "достаточно позднее включение" оно когда было??? В 70-е года прошлого тысячелетия?? Так как SQL стал стандартом ANSI уже в 80-е... "В некоторых СУБД возможно использование хранимых процедур, написанных на любом языке программирования" Ты уж договорись сам с собой.. то ты говоришь, что "многие субд уже теперь позволяют писать код на ООП" то уже что "только некоторые", но зато уже "на любых языках" :-)

Мне кажется за написание сервера (в том числе и сервера приложений) может браться очень солидная фирма, так как это приложение требует многократно больше работы программистов по его доводке, отладке и пр. Это видно в сравнении 1С и MS SQL Server: как не крути, MS SQL Server более стабильная система, у него не течет память, хотя я был очень удивлен, когда узнал, что он работает в пользовательском режиме, а база данных читается и пишется банальным WriteFile  ReadFile. Кроме того большие фирмы имеют большее количество подопытных кроликов, что с одной стороны дает возможность быстрее находить ошибки, но на мой взгляд главное, все эти кролики в какой-то мере заставляют MS доводить свой сервер до ума. Пэтому, 6 лет назад, когда я впервые сделал DCOM, я очень загорелся трехзвенкой, но сейчас, думаю, что не взялся бы. Так разве что как один из доп. модулей к системе

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

для явы уже все написано... например JBoss. П.э. там и платят за конкретные знание в конкретных фреймворках, а не за набивание строчек по синтаксису...

Что-то не то вы услышали про MSSQL "writefile и ReadFile" - никак не вяжется с тем что скульссервер может работать и с дисками без ФС.

Фигня все это. Лучше мощный сервер + терминал, для передачи картинки. Или уже по вашему передача м/у звеньями происходит мгновенно и не требует ресурсов?

это цитата вики, не ерничай

Writefile и ReadFile вообще-то умеют работать и не только с дисками, а также с портами, сокетами и другими устройствами, допускающими последовательный или блочный ввод-вывод. Только что это меняет. Я для себя сделал вывод, что MS SQL Server написан на преимущественно документированных функция, т.к. 1С вполне по силам написать аналогичное, однако не взлетает

расскажи про конфигурацию сервера терминалов на 1000 пользователей, а так же нарисуй графики зависимости загруженности серверов от количества пользователей в 77 и 8.х

Встречная просьба. Нарисуй конфигурацию серверов 1С 7.7 на 1000 пользователей. Вот и я о том же. А по поводу балансировки нагрузки ... ну так он появился в 8.2 и к 8.х имеет частичное отношение

Трёхзвенка нужна тогда, когда возникает вопрос с отложенным выполнением заданий, а также с отслеживанием взаимодействия сеансов пользователей между собой, то в режиме SQL-сервера делать достаточно сложно. Другое дело, что для некоторых задач можно и без SQL-сервера обойтись, но SQL-это структурированное и быстрое хранение данных, а также возможность BackUp-ов. А в эпоху тонких клиентов и удалённых офисов вообще четырехзвенная структура себя оправдывает: "Тонкий клиент" "Локальный сервер удалённого офиса" "Сервер обработки бизнес логики программы" "Сервер хранения данных"

Больше звеньев - больше бобла.

По сути 8.2 к этому уже приближается. Пока еще п.2 и п.3 это физически одно приложение, но логическое разделение уже наметилось.

в пивной разливушке с проходимостью 2 человека в час:

а где же вэб-сервер?

Для 1С трех звенка - это источников тормозов. В 90% случаев у нас нет неукого базы по 500Гиг, к которым одновременно 5000 юзверей подключаются. Исходя из этого даже расположение на одном серваке SQL и сервер предприятие уже дает выйгрыш заметный невооруженным глазом. Понятно что если база и система будет лежать на одном стареньком IDE винте, то лучше на разных серваках. По крайне мере за винт они не будут бороться. А если база на отдельной полке на скази винтах, темпы на рам диске, то лучше когда на одном серваке

то есть если поставить сервер предприятия, СУБД, и клиентское приложение на одну физическую машину, то система станет двух/однозвенной?))

жжошь...

Нет но в данном случае из пушки по воробьям. Т.е. если нам не нужна супере пупер масштабируемость (зачем она в ларьке из двух компов), то двухзвенка будет лучше трехзвенки. Поэтому нельзя сказать что, что-то однозначно лучше. Идеалов в этой жизни не бывает, и у каждой проблемы свои пути решения и инструменты

Опыт - сын ошибок трудный, как бы намекает, что мы работаем с 1С. Поэтому то что рассказывают в американских учебниках про MSSQL несовсем подходит в нашем случае, т.е. требует корреляции Да не я один пришел к таким выводам "При переносе SQL на сервер, где 1С вращается, производительность чуть-чуть возросла"

В некоторых случаях и "однозвенка" выгоднее :)

А вот интересно: что длиннее - твердое или горячее? А так... - конечно от решаемых задач.

Все таки про безопасность никто не рассказал При трехзвенке конечный юзер физически не видит базу и даже не знает где она расположена. Ну и про логины/пароли ничего не знает

А ролью приложения в MS SQL конечно запретили пользоваться

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

сколько общих терминов, и никакой конкретики =)

Например, пользователь открывает набор данных по какому-то клиенту и начинает там что-то менять. При этом, есть вероятность, что он эти изменения сохранит или отбросит. Можно, конечно, открывать для таких действий транзакцию, но это не есть хорошо. А перегонять все данные на клиента - тоже - особенно, если будет изменен только один параметр. Можно, конечно, отслеживать изменения на уровне записи действий, то это медленно. Теперь представим, что пользователя уже два - и они оба правят один набор данных - два пользователя в одной транзакции не живут. P.S. а так - любой учёт можно вести при помощи блокнота и калькулятора - и без всяких звеньев - и для ларька это самое оно.

ты сейчас кагбэ мне противопоставил что-то?)))

и к чему ты это?)

Просили же с конкретикой. И ничего я не противопоставлял. Собственно говоря, рассматривать SQL, кроме как хранилище данных - очень сложно. Особенно, если наплодишь объектов с разными свойствами и наборами данных, которые в SQL-то и уложить не сразу получается, а потом к ним надо ещё обращаться и запросы делать типа "SELECT Object FROM STORAGE Where Type (Equal or Derived) SimpleReference And Code Like '*123*')" И получается, что надо ещё транслятор языка запросов в SQL писать.

вода одна...

Если надо конкретно, то это будет так: Есть некоторый структурированный набор объектов. У каждого объекта может быть некоторое число прародителей (то есть объектов, свойства которых он наследует). У каждого объекта есть заранее заданный набор свойств. Мне надо этот "зверинец" сложить в базу SQL и с ним там работать. Вопрос - как это сделать, чтобы можно было потом с этими объектами работать с помощью хранимых процедур SQL-сервера ?