ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle APEX [игнор отключен] [закрыт для гостей] / Миграция на другую платформу
20 сообщений из 95, страница 4 из 4
  4  все
Миграция на другую платформу
    #38895652
Курдль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Курдль
Участник
Алексей ВыхрыстюкВсе очень просто. Торговая сеть - каждый магазин отдельная база. Центральная база тоже разбита на отдельные базы по отделам (управление персоналом, товарная логистика, управленческая отчетность и т.д. )
Самое главное в такой системе избегать обновления одних данных в разных БД. Например в торговую точку выгружаются товары,ШК,цены, обратно продажи и возвраты - данные модифицируются в одном месте.

Также можно использовать отдельные БД как blob репозитории для документов, картинок и т.д.

Вариант "каждый магазин отдельная база" - принимается.
А вот "отдельные базы по отделам" - прод большим подозрением.
Ведь между отделами разделены чертовы кучи сущностей, тесно взаимосвязанных друг с другом.
Если разорвать их на отдельные БД - потеряется основное достоинство промышленной СУБД - поддержка целостности данных.
Зачем вас вообще тогда на оракл понесло? Делали бы все на MySQL (hybernate Вам в руки...)
...
Рейтинг: 0 / 0
05.03.2015, 11:29
| Ответить | Цитировать | Написать  
Миграция на другую платформу
    #38895659
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Курдль,
+1
я вообще не понял смысл дробления. Лицензия? Размер? Скорость?
...
Рейтинг: 0 / 0
05.03.2015, 11:31
| Ответить | Цитировать | Написать  
Миграция на другую платформу
    #38895665
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
В 1С отдельные подразделения уже заложены в модель данных.
...
Рейтинг: 0 / 0
05.03.2015, 11:32
| Ответить | Цитировать | Написать  
Миграция на другую платформу
    #38895782
Фотография Алексей Выхрыстюк
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей Выхрыстюк
Участник
КурдльАлексей ВыхрыстюкВсе очень просто. Торговая сеть - каждый магазин отдельная база. Центральная база тоже разбита на отдельные базы по отделам (управление персоналом, товарная логистика, управленческая отчетность и т.д. )
Самое главное в такой системе избегать обновления одних данных в разных БД. Например в торговую точку выгружаются товары,ШК,цены, обратно продажи и возвраты - данные модифицируются в одном месте.

Также можно использовать отдельные БД как blob репозитории для документов, картинок и т.д.

Вариант "каждый магазин отдельная база" - принимается.
А вот "отдельные базы по отделам" - прод большим подозрением.
Ведь между отделами разделены чертовы кучи сущностей, тесно взаимосвязанных друг с другом.
Если разорвать их на отдельные БД - потеряется основное достоинство промышленной СУБД - поддержка целостности данных.
Зачем вас вообще тогда на оракл понесло? Делали бы все на MySQL (hybernate Вам в руки...)

Вначале была одна база...

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

В случае использования одной БД - данные отделов приходится все равно хранить в отдельных сущностях.
...
Рейтинг: 0 / 0
05.03.2015, 12:26
| Ответить | Цитировать | Написать  
Миграция на другую платформу
    #38895801
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Алексей ВыхрыстюкВ случае использования одной БД - данные отделов приходится все равно хранить в отдельных сущностях.
нет. В модели уже есть сужность Документ с атрибутом - Отдел\Подразделение.
Передавай как угодно из отдела в отдел.
...
Рейтинг: 0 / 0
05.03.2015, 12:36
| Ответить | Цитировать | Написать  
Миграция на другую платформу
    #38895806
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
если вместо атрибута Отдел - делать экземпляр БД, то невозможно сделать консолидированные отчёты и т.д.
...
Рейтинг: 0 / 0
05.03.2015, 12:37
| Ответить | Цитировать | Написать  
Миграция на другую платформу
    #38895822
irbis_al
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
irbis_al
Участник
Petro123если вместо атрибута Отдел - делать экземпляр БД, то невозможно сделать консолидированные отчёты и т.д.

Почему...Это классическая иерархическая схема...
Данные на каждой субд агрегируются и передаются наверх в верхнюю СУБД.
И Как раз консолидированный отчёт просто сделать.
Сложнее сделать отчёт с ньюансами характерными для нижней СУБД.
Надо именно к ней подключатся.
...
Рейтинг: 0 / 0
05.03.2015, 12:48
| Ответить | Цитировать | Написать  
Миграция на другую платформу
    #38895829
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
irbis_al,
ну, я тебе привёл сущность с атрибутом. Но это OFF для данной темы.
...
Рейтинг: 0 / 0
05.03.2015, 12:51
| Ответить | Цитировать | Написать  
Миграция на другую платформу
    #38895861
Casufi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Casufi
Участник
Алексей ВыхрыстюкОграничение идеи с использованием связанных XE - одна таблица не может быть больше 11 гиг. Если я не ошибаюсь в postgre тоже похожее ограничение.
32 терабайта. На пуркуа обсуждать то, в чем ноль ? Это же касается Petro123
...
Рейтинг: 0 / 0
05.03.2015, 13:12
| Ответить | Цитировать | Написать  
Миграция на другую платформу
    #38895864
Casufi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Casufi
Участник
Petro123я вообще не понял смысл дробления. Лицензия? Размер? Скорость? Чтобы использовать Oracle XE, я так понял.
...
Рейтинг: 0 / 0
05.03.2015, 13:13
| Ответить | Цитировать | Написать  
Миграция на другую платформу
    #38895874
Курдль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Курдль
Участник
Алексей ВыхрыстюкВ случае использования одной БД - данные отделов приходится все равно хранить в отдельных сущностях.
В страшном сне себе не могу такое представить...

Если на примере документов.

Есть сущность ДОКУМЕНТ
Есть сущность ПОДРАЗДЕЛЕНИЕ
Установить 2 связи много-к-одному от документа к подразделению.
Для одной, со стороны подразделения установить роль "Источник", для второй - "Приемник".

Это для простого примера передачи от одного к другому подразделению.
Если существует какой-то процесс приемки-передачи, согласования, подписи и т.п. (жизненный цикл документа) то надо моделировать ПРОЦЕСС в ОДНОЙ БД.
...
Рейтинг: 0 / 0
05.03.2015, 13:17
| Ответить | Цитировать | Написать  
Миграция на другую платформу
    #38895878
Casufi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Casufi
Участник
КурдльВ страшном сне себе не могу такое представить...

Если на примере документов.
Я так понял, весь это изврат делался ради того, чтобы использовать только Oracle XE и не вылазить за ограничения. Какой смысл обсуждат архитектуру не учитывая этого ?
...
Рейтинг: 0 / 0
05.03.2015, 13:20
| Ответить | Цитировать | Написать  
Миграция на другую платформу
    #38895896
Курдль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Курдль
Участник
CasufiКурдльВ страшном сне себе не могу такое представить...

Если на примере документов.
Я так понял, весь это изврат делался ради того, чтобы использовать только Oracle XE и не вылазить за ограничения. Какой смысл обсуждат архитектуру не учитывая этого ?

Да я бы отвял, если бы автор сразу признался, "да, мы минимизируем затраты ценой потери целостности данных" :)
Так нет же! Он утверждает, что и для архитектуры данных это благо.
...
Рейтинг: 0 / 0
05.03.2015, 13:29
| Ответить | Цитировать | Написать  
Миграция на другую платформу
    #38895919
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
OFF
Casufiчтобы использовать только Oracle XE и не вылазить за ограничения. Какой смысл обсуждат архитектуру не учитывая этого ?
это ещё глупее для масштабируемости.
Подгонять Модель под размер БД.
Лучше бы в архив сбрасывал свой терабайт или OLAP\OLTP или..
Короче, не надо изврат на XE делать. Заказчик не купит
(утрирую)
...
Рейтинг: 0 / 0
05.03.2015, 13:37
| Ответить | Цитировать | Написать  
Миграция на другую платформу
    #38895925
облом
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
облом
Гость
CasufiЯ так понял, весь это изврат делался ради того, чтобы использовать только Oracle XE и не вылазить за ограниченияТогда это до одного места, т.к. в лицензии сказано "не более одной инсталяции на всех серверах"
http://www.oracle.com/technetwork/licenses/database-11g-express-license-459621.html]1. Express Edition is limited to a single instance on any server
...
Рейтинг: 0 / 0
05.03.2015, 13:41
| Ответить | Цитировать | Написать  
Миграция на другую платформу
    #38895938
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
облом,
на одном хосту. Он линки на 50 хостов сделает.
...
Рейтинг: 0 / 0
05.03.2015, 13:46
| Ответить | Цитировать | Написать  
Миграция на другую платформу
    #38895983
Курдль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Курдль
Участник
Алексей ВыхрыстюкВ случае использования одной БД - данные отделов приходится все равно хранить в отдельных сущностях.
Алексей! Вы не подумайте, что я тролю...
Мне действительно интересно. Похоже это концепция моделирования, которую я неоправданно проигнорировал.
Подскажите, если "данные отделов приходится хранить в разных сущностях", значит ли это, что при перемещении документа из одного отдела в другой, он "удаляется из сущности 1-го отдела" и "добавляется в сущность 2-го отдела"?
...
Рейтинг: 0 / 0
05.03.2015, 14:14
| Ответить | Цитировать | Написать  
Миграция на другую платформу
    #38896002
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
Курдль,
в бухгалтерии они вроде не перемещаются. Только в в СЭД - сист.электронн.документооб.
...
Рейтинг: 0 / 0
05.03.2015, 14:21
| Ответить | Цитировать | Написать  
Миграция на другую платформу
    #38896064
Фотография Алексей Выхрыстюк
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Алексей Выхрыстюк
Участник
КурдльАлексей ВыхрыстюкВ случае использования одной БД - данные отделов приходится все равно хранить в отдельных сущностях.
Алексей! Вы не подумайте, что я тролю...
Мне действительно интересно. Похоже это концепция моделирования, которую я неоправданно проигнорировал.
Подскажите, если "данные отделов приходится хранить в разных сущностях", значит ли это, что при перемещении документа из одного отдела в другой, он "удаляется из сущности 1-го отдела" и "добавляется в сущность 2-го отдела"?

Скорее всего не удаляется,а помечается удаленным. Во втором отделе появляется новая запись. Если взять УПП 1С, то для разных организаций происходит тоже самое - в одной расход в другой приход.
...
Рейтинг: 0 / 0
05.03.2015, 14:46
| Ответить | Цитировать | Написать  
Миграция на другую платформу
    #38896314
kasik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kasik
Участник
Что то вы отвлеклись от темы! Такое в проектировании обсуждают
...
Рейтинг: 0 / 0
05.03.2015, 16:47
| Ответить | Цитировать | Написать  
20 сообщений из 95, страница 4 из 4
  4  все
Форумы / Oracle APEX [игнор отключен] [закрыт для гостей] / Миграция на другую платформу
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=50&msg=38895806&tid=1875058]:
 0ms
get settings:
 11ms
get forum list:
 17ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 78ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 63ms
get tp. blocked users:
 2ms
others: 243ms
total:  437ms
созд. / загр.: 437ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]