1. C# как язык. Для рисования форм VisualStudio. Для описания бизнеслогики своя IDE
2. Наша система как раз скорее монолит. Т.е. понятия модуль как фалик с функционалом — нет.
Как следствие, нет выпуска обновлений — система всегда заточена под заказчика.
4. Начать надо с того что аналитик занимается анализом задачи, ее проектирует решение внедряет его. Указанные действия не работа аналитика, однако да, он может поменять форму и настроить колонки. Последнее не понял если честно, но думаю, что нет.
Подробнее есть на сайте платформы.
Саповские консультанты настолько суровы, что всего лишь снисходительной усмешкой и лапидарным «бред» способны опровергнуть любую сколь угодно прочно обоснованную позицию.
С другой стороны, а что им еще остается? Для повышения настроения ваших коллег рекомендуем еще пару ссылочек: www.ultimaerp.com/compare/sap/, www.ultimaerp.com/library/sap300/.
Касательно тезиса, что «абсолютно неважно, какую систему ты внедряешь» — экспрессивность и глубокомысленность сообщения намекает, что спорить с ним не следует. Тем более, что у нас такой задачи и нет и тем более, что в приведенных ссылках на эту тему, в общем, все сказано.
Количество наших внедрений не имеет логической связи ни с комментируемым вами текстом, ни с любым другим опубликованным здесь или у нас на сайте. Переменная Х, содержащая количество внедрений продуктов компании Ultima, в аргументации нигде не участвует. Хотя их, безусловно, несколько больше пяти.
P.S. Что-то вдруг вспомнилось из Жванецкого:
«Мы овладеваем более высоким стилем спора. Спор без фактов. Спор на темпераменте. Спор, переходящий от голословного утверждения на личность партнера.
Что может говорить хромой об искусстве Герберта фон Караяна? Если ему сразу заявить, что он хромой, он признает себя побежденным.
О чем может спорить человек, который не поменял паспорт? Какие взгляды на архитектуру может высказать мужчина без прописки? Пойманный с поличным, он сознается и признает себя побежденным.
И вообще, разве нас может интересовать мнение человека лысого, с таким носом? Пусть сначала исправит нос, отрастит волосы, а потом и выскажется.»
Пардон. Написал, что «LOG_CHANGES — информацию, о изменении в таблице, пользователя и сессии из которой сделано изменение. », расшифровываю:
Session_id это ссылка на сессию, которая «живет» на сервере приложений (в отличие от сессий-соединений к БД, у которых свой жизненный цикл), создается в момент создания подключения пользователя к серверу приложений. Там мы храним всю информацию — с какого компа, из-под какого пользователя произведен вход. Методы GET_REAL_UID и GET_SESSION_ID возвращают не ораклового, а пользователя системы и текущую сессию в описанном выше смысле.
Я посчитал это лишними деталями. В нашем конкретном случае мы пользуемся такой возможностью Oracle Database как Context — упрощенно, позволяет хранить key-value пары на время жизни сессии.
1. Тут необходимо вспомнить такую фичу Oracle как Partitioning. Поле оставлено для него.
2. как раз из-за п. 1 такое API не требуется (точнее решается средствами БД)
3. Ничего нового — индексы, хотя и реверсивные. Растут быстро таблицы, но время поиска растет логарифмически, что приемлемо. Ну и партиционирование сильно помогает.
4. Ну у нас разделены протоколирование типа «Сумма превысила ХХХ» и просто внесены изменения. Разделение необходимо, поскольку при работе с большими данными приходится опускаться до уровня SQL запросов, и следовательно реализовывать логгирование на уровне БД. А события типа «Сумма превысила ХХХ» это уровня бизнес-логики и сделано на уровне сервера приложений.
Собственно весь наш сервер приложений это обработка тех или иных событий.
Модульные системы не обязанны лежать в разных бд. Но по факту так и есть, во много исходя из истории их возникновения, я в статье решил не углублятся. В статье на нашем сайте чуть подробнее про это есть.
По второму. Я там ведь дальше написал что нельзя так формально подходить к этому определению. В приведенном Вами примере складской модуль самодостаточен с точки зрения сотрудников склада, ибо покрывает все их потребности.
Если Вы будете отталкиваться от требований предметной области и разрабатывать систему с нуля, то у вас для ERP систем как раз и получится скорее монолитная система, ибо там все утыкано «единая и неделимая операция». А если будете отталкиваться от того, что есть, то модульная.
Главное в данном случае — не приносить бизнес-требования в жертву неким архитектурным догмам, что часто встречается.
Позволю не согласиться.
В реальных проектах размеры баз составляют терабайты (в одном проекте скоро начнем считать десятками).
Один сервер конечно когда-то перестанет тянуть, поэтому современные СУБД имеют функции кластеризации (у Oracle — Real Application Cluster). Надо понимать, что этот кластер с точки зрения сервера приложений — все так же одна база. Кроме того, благодаря логарифмической сложности поиска скорость падает медленно. Упрощая, но по сути верно — для поиска среди 4 000 000 000 (4-х миллиардов) записей надо сделать 32 чтения, а среди 8 000 000 000 (8-ми миллиардов) требуется 33, для 16 — 34. Кроме того, у баз данных есть и другие технологии, которые упрощают работу с большими таблицами.
В каком смысле «что внутри»?
Создание новой отдельной транзакции.
Разница в том, что мы не исключили доступ, а в том, что убрали возможность все сломать управляя транзакциями вручную.
Еще раз укажу на то, что на терминалах крутится сайт. Терминал это именно терминал, на нем только браузер и запущен, ОС на флешке. Из настроек только урл, который открывать. Вы предлагаете иметь мальчика, который бегает и настраивает эти терминалы? Мальчик 30тыр минимум стоит.
Второе — что собственно распечатывается. Товарный чек со всеми опциями оплаты бонусами, безналом или еще как. У нас конечно можно экспортировать печатную форму в pdf и передать ее вебсерверу, тот на терминал и тот распечатает. Можно просто напечатать.
Второй вариант — при оплате в кассе распечатать листы набора на складе. Оплата в кассе — обработка некоторой бизнеслогики на сервере приложений.
>Если печатает сервер печати, то:
>1. При установке принтера его нужно как то зарегистрировать на сервере печати.
>2. При установке клиента нужно указать, на какой принтер (из зарегистрированных на сервере печати) выдавать >печать.
Или его нужно зарегистрировать на терминале. При какой установке клиента вообще не понял?
>Оба этих действия должен совершить уже не просто админ, а специалист в ERP системе. Т.е., мне кажется, >схема усложнилась. А что взамен?
Ну если человек способен подключить принтер, то и кликнуть в пару кнопок в системе тоже справится.
2. Наша система как раз скорее монолит. Т.е. понятия модуль как фалик с функционалом — нет.
Как следствие, нет выпуска обновлений — система всегда заточена под заказчика.
4. Начать надо с того что аналитик занимается анализом задачи, ее проектирует решение внедряет его. Указанные действия не работа аналитика, однако да, он может поменять форму и настроить колонки. Последнее не понял если честно, но думаю, что нет.
Подробнее есть на сайте платформы.
С другой стороны, а что им еще остается? Для повышения настроения ваших коллег рекомендуем еще пару ссылочек: www.ultimaerp.com/compare/sap/, www.ultimaerp.com/library/sap300/.
Касательно тезиса, что «абсолютно неважно, какую систему ты внедряешь» — экспрессивность и глубокомысленность сообщения намекает, что спорить с ним не следует. Тем более, что у нас такой задачи и нет и тем более, что в приведенных ссылках на эту тему, в общем, все сказано.
Количество наших внедрений не имеет логической связи ни с комментируемым вами текстом, ни с любым другим опубликованным здесь или у нас на сайте. Переменная Х, содержащая количество внедрений продуктов компании Ultima, в аргументации нигде не участвует. Хотя их, безусловно, несколько больше пяти.
P.S. Что-то вдруг вспомнилось из Жванецкого:
«Мы овладеваем более высоким стилем спора. Спор без фактов. Спор на темпераменте. Спор, переходящий от голословного утверждения на личность партнера.
Что может говорить хромой об искусстве Герберта фон Караяна? Если ему сразу заявить, что он хромой, он признает себя побежденным.
О чем может спорить человек, который не поменял паспорт? Какие взгляды на архитектуру может высказать мужчина без прописки? Пойманный с поличным, он сознается и признает себя побежденным.
И вообще, разве нас может интересовать мнение человека лысого, с таким носом? Пусть сначала исправит нос, отрастит волосы, а потом и выскажется.»
Session_id это ссылка на сессию, которая «живет» на сервере приложений (в отличие от сессий-соединений к БД, у которых свой жизненный цикл), создается в момент создания подключения пользователя к серверу приложений. Там мы храним всю информацию — с какого компа, из-под какого пользователя произведен вход. Методы GET_REAL_UID и GET_SESSION_ID возвращают не ораклового, а пользователя системы и текущую сессию в описанном выше смысле.
2. как раз из-за п. 1 такое API не требуется (точнее решается средствами БД)
3. Ничего нового — индексы, хотя и реверсивные. Растут быстро таблицы, но время поиска растет логарифмически, что приемлемо. Ну и партиционирование сильно помогает.
4. Ну у нас разделены протоколирование типа «Сумма превысила ХХХ» и просто внесены изменения. Разделение необходимо, поскольку при работе с большими данными приходится опускаться до уровня SQL запросов, и следовательно реализовывать логгирование на уровне БД. А события типа «Сумма превысила ХХХ» это уровня бизнес-логики и сделано на уровне сервера приложений.
Собственно весь наш сервер приложений это обработка тех или иных событий.
По второму. Я там ведь дальше написал что нельзя так формально подходить к этому определению. В приведенном Вами примере складской модуль самодостаточен с точки зрения сотрудников склада, ибо покрывает все их потребности.
Если Вы будете отталкиваться от требований предметной области и разрабатывать систему с нуля, то у вас для ERP систем как раз и получится скорее монолитная система, ибо там все утыкано «единая и неделимая операция». А если будете отталкиваться от того, что есть, то модульная.
Главное в данном случае — не приносить бизнес-требования в жертву неким архитектурным догмам, что часто встречается.
В реальных проектах размеры баз составляют терабайты (в одном проекте скоро начнем считать десятками).
Один сервер конечно когда-то перестанет тянуть, поэтому современные СУБД имеют функции кластеризации (у Oracle — Real Application Cluster). Надо понимать, что этот кластер с точки зрения сервера приложений — все так же одна база. Кроме того, благодаря логарифмической сложности поиска скорость падает медленно. Упрощая, но по сути верно — для поиска среди 4 000 000 000 (4-х миллиардов) записей надо сделать 32 чтения, а среди 8 000 000 000 (8-ми миллиардов) требуется 33, для 16 — 34. Кроме того, у баз данных есть и другие технологии, которые упрощают работу с большими таблицами.
Создание новой отдельной транзакции.
Разница в том, что мы не исключили доступ, а в том, что убрали возможность все сломать управляя транзакциями вручную.
Второе — что собственно распечатывается. Товарный чек со всеми опциями оплаты бонусами, безналом или еще как. У нас конечно можно экспортировать печатную форму в pdf и передать ее вебсерверу, тот на терминал и тот распечатает. Можно просто напечатать.
Второй вариант — при оплате в кассе распечатать листы набора на складе. Оплата в кассе — обработка некоторой бизнеслогики на сервере приложений.
>Если печатает сервер печати, то:
>1. При установке принтера его нужно как то зарегистрировать на сервере печати.
>2. При установке клиента нужно указать, на какой принтер (из зарегистрированных на сервере печати) выдавать >печать.
Или его нужно зарегистрировать на терминале. При какой установке клиента вообще не понял?
>Оба этих действия должен совершить уже не просто админ, а специалист в ERP системе. Т.е., мне кажется, >схема усложнилась. А что взамен?
Ну если человек способен подключить принтер, то и кликнуть в пару кнопок в системе тоже справится.