Имеет ли смысл "слой отображения" разместить в отдельной БД на отдельном сервере.. можно обозвать "пласт отображения". Например, витрину wеб магазина реализовать в ввиде отдельной подсистемы, а более медленные операции по складскому учёту, автоматизации бизнес процессов по обработке заказов, отчётность реализовать в другой подсистеме со своей собственной БД?

На витрине реализуется лёгкая логика выбора оформления заказа Основное внимание уделяется разного рода сервисам и скорости и надёжности (снижению времени простоя).

Доводы за разделение подсистем:
1) Витрину засчёт простоты легче сделать быстрой и надёжной. БД витритны используется лишь для хранения оперативных данных и данных отвечающих за представление (различного рода настройки представления, сортировки, параметры отображения), . При использовании ASP.NET можно ограничиться упрощёнными решениями (модуль/шлюз таблицы и т.п.) для выделения бизнес логики.

2) Навороченную логику автоматизации бизнес процессов можно реализовать в полный рост. Сервер допустипо перегружать при операциях развёртывания и т.п. Отчёты не будут валить систему по понедельниками и первым числам.

3) наплывы пользователей (после массовых рекламных компаний пик посещаемости может возвышаться над средней посещаемость в рабочее время до пяти раз) и DOS атаки не парализуют систему складского учёта.

Доводы против:
1)требуется тратить дополнительные ресурсы на синхронизацию товара в двух подсистемах.

Периодически натыкаюсь на статьи (про Diasoft, про ozon http://www.microsoft.com/rus/business/casestudies/ozon/) которые описывают подобные решения. Однако разбирают сомнения — неужели сейчас с применение трёх звенных систем ( с выделенным сервером приложения) нельзя добиться тех же результато?

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

GO_>Имеет ли смысл "слой отображения" разместить в отдельной БД на отдельном сервере.. можно обозвать "пласт отображения". Например, витрину wеб магазина реализовать в ввиде отдельной подсистемы, а более медленные операции по складскому учёту, автоматизации бизнес процессов по обработке заказов, отчётность реализовать в другой подсистеме со своей собственной БД?

GO_>На витрине реализуется лёгкая логика выбора оформления заказа Основное внимание уделяется разного рода сервисам и скорости и надёжности (снижению времени простоя).

GO_>Доводы за разделение подсистем:
GO_>1) Витрину засчёт простоты легче сделать быстрой и надёжной. БД витритны используется лишь для хранения оперативных данных и данных отвечающих за представление (различного рода настройки представления, сортировки, параметры отображения), . При использовании ASP.NET можно ограничиться упрощёнными решениями (модуль/шлюз таблицы и т.п.) для выделения бизнес логики.

GO_>2) Навороченную логику автоматизации бизнес процессов можно реализовать в полный рост. Сервер допустипо перегружать при операциях развёртывания и т.п. Отчёты не будут валить систему по понедельниками и первым числам.

GO_>3) наплывы пользователей (после массовых рекламных компаний пик посещаемости может возвышаться над средней посещаемость в рабочее время до пяти раз) и DOS атаки не парализуют систему складского учёта.

GO_>Доводы против:
GO_>1)требуется тратить дополнительные ресурсы на синхронизацию товара в двух подсистемах.

GO_>Периодически натыкаюсь на статьи (про Diasoft, про ozon http://www.microsoft.com/rus/business/casestudies/ozon/) которые описывают подобные решения. Однако разбирают сомнения — неужели сейчас с применение трёх звенных систем ( с выделенным сервером приложения) нельзя добиться тех же результато?

Для отчетов можно использовать OLAP технологию, а между БД настроить репликацию (в основе OLAP лежат ненормализованные таблицы).

В случае разноса товаров будет гемор с остатками — за них будут конкурировать с двух сторон без возможности синхронизировать и разрулить.
Осталось на складе 5 штук — менеджер их продал. И на сайте чувак 5 штук заказал. Что дальше?

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

iT>В случае разноса товаров будет гемор с остатками — за них будут конкурировать с двух сторон без возможности синхронизировать и разрулить.
iT>Осталось на складе 5 штук — менеджер их продал. И на сайте чувак 5 штук заказал. Что дальше?
Продажи идут только с сайта. Другое дело что со склада товар можно списать или вернуть поставщику. Но для этого его надо сперва вывести из продажи с сайта и эта проблема решается.

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


А>Для отчетов можно использовать OLAP технологию, а между БД настроить репликацию (в основе OLAP лежат ненормализованные таблицы).
Спасибо, тем более средства OLAP чуть ли не встроены в SQL 2005.

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


GO_>Продажи идут только с сайта. Другое дело что со склада товар можно списать или вернуть поставщику. Но для этого его надо сперва вывести из продажи с сайта и эта проблема решается.

В том — то и проблема что ты не сможешь сделать в одной транзакции списание товара {"Удалить товар с сайта", "Вернуть товар поставщику"} — у тебя будут две отдельные транзакции — каждая над своей базой данных: "Удалить товар с сайта" и "Вернуть товар поставщику"

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

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


GO_>>Продажи идут только с сайта. Другое дело что со склада товар можно списать или вернуть поставщику. Но для этого его надо сперва вывести из продажи с сайта и эта проблема решается.

_>В том — то и проблема что ты не сможешь сделать в одной транзакции списание товара {"Удалить товар с сайта", "Вернуть товар поставщику"} — у тебя будут две отдельные транзакции — каждая над своей базой данных: "Удалить товар с сайта" и "Вернуть товар поставщику"
Мм... Моё текущее представление о задаче не согласенно с таким суждением.
Дело в том, что удалить товар с сайта и вернуть товар поставщику — две транзакции: первая переносит товар с витрины на склад магазина, вторая со складского комплекса магазина поставщику (на склад поставщика фактически).
Можно представит сайт как витрину оффлайнового магазина (блестящую, приятную на ощупь, с улыбчивым и радушным персоналом), а складскую систему как утилитарное помещение с пыльными грузчиками. (Хотя если вводить сущность "склад", то у витрины мы обнаружим покрайней мере один её экземпляр). Причём со складского помещения мы может отправлять товар на несколько витрин (сайтов). Поэтому "убрать товар с витрины" (товар перемещается на склад) и "вернуть товар поставщику" (со склада на грузовичок.. скорее всего на другой склад) — это две разных операции. Или я не прав?

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

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

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


GO_>>>Продажи идут только с сайта. Другое дело что со склада товар можно списать или вернуть поставщику. Но для этого его надо сперва вывести из продажи с сайта и эта проблема решается.

_>>В том — то и проблема что ты не сможешь сделать в одной транзакции списание товара {"Удалить товар с сайта", "Вернуть товар поставщику"} — у тебя будут две отдельные транзакции — каждая над своей базой данных: "Удалить товар с сайта" и "Вернуть товар поставщику"
GO_>Мм... Моё текущее представление о задаче не согласенно с таким суждением.
GO_>Дело в том, что удалить товар с сайта и вернуть товар поставщику — две транзакции: первая переносит товар с витрины на склад магазина, вторая со складского комплекса магазина поставщику (на склад поставщика фактически).
GO_>Можно представит сайт как витрину оффлайнового магазина (блестящую, приятную на ощупь, с улыбчивым и радушным персоналом), а складскую систему как утилитарное помещение с пыльными грузчиками. (Хотя если вводить сущность "склад", то у витрины мы обнаружим покрайней мере один её экземпляр). Причём со складского помещения мы может отправлять товар на несколько витрин (сайтов). Поэтому "убрать товар с витрины" (товар перемещается на склад) и "вернуть товар поставщику" (со склада на грузовичок.. скорее всего на другой склад) — это две разных операции. Или я не прав?

А как же тогда бухгалтерам учитывать товар, который лежит на витрине. У них в системе товар, который направили на продажу, будет исчезать, хотя этот товар ещё не продан.

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

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

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


GO_>>>Продажи идут только с сайта. Другое дело что со склада товар можно списать или вернуть поставщику. Но для этого его надо сперва вывести из продажи с сайта и эта проблема решается.

_>>В том — то и проблема что ты не сможешь сделать в одной транзакции списание товара {"Удалить товар с сайта", "Вернуть товар поставщику"} — у тебя будут две отдельные транзакции — каждая над своей базой данных: "Удалить товар с сайта" и "Вернуть товар поставщику"
GO_>Мм... Моё текущее представление о задаче не согласенно с таким суждением.
GO_>Дело в том, что удалить товар с сайта и вернуть товар поставщику — две транзакции: первая переносит товар с витрины на склад магазина, вторая со складского комплекса магазина поставщику (на склад поставщика фактически).
GO_>Можно представит сайт как витрину оффлайнового магазина (блестящую, приятную на ощупь, с улыбчивым и радушным персоналом), а складскую систему как утилитарное помещение с пыльными грузчиками. (Хотя если вводить сущность "склад", то у витрины мы обнаружим покрайней мере один её экземпляр). Причём со складского помещения мы может отправлять товар на несколько витрин (сайтов). Поэтому "убрать товар с витрины" (товар перемещается на склад) и "вернуть товар поставщику" (со склада на грузовичок.. скорее всего на другой склад) — это две разных операции. Или я не прав?

Я не совсем правильно высказался... "Списать товар" состоит из 2 — х разных примитивных операций "Убрать товар с витрины" (все равно куда отправился товар обратно на склад или покупателю — из таблицы "Товары" б.д. "Магазин" запись удаляется) и "Добавить товар на склад" (все равно откуда товар прибыл — в таблицу "Товары" б.д. "Склад" добавляется запись) и они должны быть аттомарными. Я к тому что транзакции действуют на уровне б.д. и у Вас бвозможна ситуация при которой товар просто исчез из магазина... Но я не знаю может быть вы нашли какое — то решение этой проблемы?

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


_>А как же тогда бухгалтерам учитывать товар, который лежит на витрине. У них в системе товар, который направили на продажу, будет исчезать, хотя этот товар ещё не продан.

Я несколько разделяю понятия "складской учёт" и "бух учёт". Поскольку склад интернет магазина и "склад" (суть местоположение товара) витрины принадлежат одному и томуже субъекту (физическому или юридическому лицу) то движений по бух учёту я здесь не наблюдаю. А вот когда товар будет продан (а например с предоплатой заказа товар всё ещё может "находить место" на складе) тогда движение денежек и пойдёт.В прочем, бухучёт для меня тёмный лес.