Member 10377426 Ответов: 2

Какова наилучшая архитектура проектирования баз данных в SQL server для нескольких ERP-решений ?


Question : What is best Database Design Architecture in SQL Server For Multiple ERP Solutions ?
I Already looked at AdventureWorks Database Schema of Microsoft, it looks cool but many inheritance and i didnt fit with it.

What i mean by question that i want to design an ERP Solutions plus Car Rent System, Hospital System and Hotel System and so on of any Commercial Solutions. so i decide to make a database Schemas inside SQL Server, for example :

Examples Of Schema that i guessed

dbo.schema for default tables such as ErrorHandling, BuildVersion ..

HR Schema for human resources
Inventory Schema for inventory and sales systems
Accounting Schema for Accounting system.
and so on ...
so the tables will look like that :

every tables inside it's schema system - Inventory.Sales

Inventory.Purchases
Inventory.Reports
Inventory.OrderHeader
Inventory.OrderDetail

Car.Contracts
Car.OpenedContracts
Car.ClosedContracts
Car.Types
Car.etc..>>

Accounting.Transcations
Accounting.CostCenters
Accounting.AccountL1
Accounting.AccountL2
and so on ..
1-But.. i also wanna make my databases like this structure:

-- Year Databases to reset it every beginning of year and start new one.
ERPYear012016
ERPYear012017
ERPYear012018

-- General Database that contains Static Items ( Car types, Persons )
ERPGeneral01 -> For example Company number one
ERPGeneral02 -> company number 2

But I found this ideas will make my database too large because each system will be more than 100 + Tables ? does this make cost performance to be slow in Query and affect the database itself ?

2-Or should i Make Every System Standalone ?

for example :

CarYear012016
CarYear012015

InventoryYear012016
InventoryYear012017

does this make performance great rather than only one database contains everything ?
Because not all our Customers/clients will purchase all packages, some customers need only Car System Package... that's why i need to know the best way to make Great Performance and good design ?

I Need Good Deisgn
High Performance
Fast Query
Also i wanna put this notes: if i make standalone database for each system like Car System :

CarYear012016
CarYear012017

i can here insert many schemas as i can for car system, and that make database good to understand for example .
Contracts Schema
Car Types Schema
Rent Schema
is this good >? i don't know.

The Main Questions Is Which Approach Is good in design and Performance ?

First One : Insert All ERP Systems inside Years Databases ( 2015,2016,..) ?

Second Approach : insert Every ERP in single Database ( Car2016,Car2017,Inventory2016) ?


Что я уже пробовал:

Я попробовал подход AdventureWorks, но он, похоже, не может четко вписаться в ERP-решение, потому что я хочу добавить базы данных Years. ТАК ЧТО, ПОЖАЛУЙСТА, СКАЖИТЕ МНЕ ХОРОШИЙ ПОДХОД .

2 Ответов

Рейтинг:
5

Wendelius

Есть много влияющих факторов. Некоторые размышления:


  • Наличие совершенно разных схем в разных базах данных имело бы смысл. Особенно если вы рассматриваете лицензирование только частей продукта, модульный подход облегчит лицензирование. Например, вы можете купить только модуль счетов и т. д. Однако если ваша система будет иметь много кросс-функциональных запросов, то наличие одной базы данных будет работать лучше или, по крайней мере, будет легче сделать работу лучше.
  • На мой взгляд, количество таблиц не является существенным фактором производительности. Вот как вы их используете. Я считаю, что нет смысла идти на ненужные компромиссы по стоимости нормализации только для того, чтобы попытаться уменьшить количество таблиц. Это легко приводит к денормализации, которая затем снова вызывает дублирование данных, что снова приводит либо к дополнительным операциям для поддержания их актуальности, либо к получению ложных данных.
  • Теперь, что касается взлома баз данных на годы, я бы этого не сделал. Это усложняет конструкцию и вызывает операции технического обслуживания. Если база данных хорошо спроектирована и поддерживается, вы, вероятно, сможете обрабатывать очень большие объемы данных без проблем. И если объем данных действительно начинает вызывать проблемы, у вас есть технические возможности, которые невидимы для программы, например Секционированные таблицы и индексы[^].


[no name]

Да, но наши пользователи должны очистить предыдущую базу данных за год ... Я имею в виду DeAttach предыдущего года с исполняемым проектом ?
то, что я понимаю для вас, что только одна база данных за все годы хороша. и показывать только пользовательский год внутри исполняемого файла проекта ? ты это имеешь в виду? в любом случае хороший ответ, но я хочу хорошую технику, можете ли вы дать мне несколько советов .... Спасибо!

Wendelius

Не уверен, что вы подразумеваете под очисткой предыдущего года базы данных, но если вы хотите получить значения только из текущего года, то это будет условием в операторах SQL. Например, если у вас есть столбец RowAdded в таблице, то у вас будет сравнение, что RowAdded больше или равно первому дню года.

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

[no name]

Я имею в виду, что у нас есть исполняемый проект, который показывает все годы баз данных, клиент выбирает год, с которым ему нужно работать, потому что каждый год имеет пользовательские транзакции, продажи. но если я сделаю единую базу данных, которая содержит все годы. это может быть трудно поддерживать, если мне нужно получить таблицы или строки Year2007... а также единую базу данных, если мне нужна резервная копия от клиента, я возьму файл размером более 2 ГБ ! можете ли вы сказать мне, какой хороший подход, если мне нужно работать с базой данных нескольких лет, и я просто могу получить резервную копию текущего года от клиента легкого и небольшого размера...? Спасибо ,

Wendelius

Я не уверен, что следую этому примеру, но, как я уже говорил ранее, лично я бы использовал единую базу данных за все годы и одну таблицу. Поэтому я бы не стал разделять данные по годам.

Я не совсем понимаю, почему вы беспокоитесь о размере резервной копии 2 ГБ. При нынешних размерах дисков 2 ГБ-это почти ничто, гораздо меньше, чем DVD.

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

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

Рейтинг:
19

Mehdi Gholam

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

Разбиение ваших данных на годы (на разные базы данных) будет более эффективным, так как данных будет меньше.

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


[no name]

Итак, каков наилучший подход ^^ несколько лет баз данных для каждого решения или несколько лет для всех ERP-решений ?

Mehdi Gholam

Начните с единой базы данных для всех приложений и всех лет.

[no name]

Я имею в виду, что у нас есть исполняемый проект, который показывает все годы баз данных, клиент выбирает год, с которым ему нужно работать, потому что каждый год имеет пользовательские транзакции, продажи. но если я сделаю единую базу данных, которая содержит все годы. это может быть трудно поддерживать, если мне нужно получить таблицы или строки Year2007... а также единую базу данных, если мне нужна резервная копия от клиента, я возьму файл размером более 2 ГБ ! можете ли вы сказать мне, какой хороший подход, если мне нужно работать с базой данных нескольких лет, и я просто могу получить резервную копию текущего года от клиента легкого и небольшого размера...? Спасибо ,