Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Background: we are architecting a new way to organize data in our databases and the DB team is likely to go with a 'Core' database with common data specific to our business area, and a separate database for each application that needs this data. Lets say a single one would be 'MyApplication'. These databases would all reside on the same named instance on the same server.
Question: How can I surface the tables, stored procedures, and data from 'Core' into an application that is pointing to the 'MyApplication' database?
I'm aware we could have the applications reference the other database directly, but this complicates things for the applications and is not preferred. Our original idea was creating writable views in the 'MyApplication' database for all of the objects in 'Core', but there might be performance concerns with this route.
If the complications you are trying to avoid are security and logical object separation for code readability, you might consider creating separate schemas in your CORE database for each of your applications. You could also possibly employ application roles to aid with security.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 months ago.
Improve this question
I have a project that started simply enough with EF Core code first. I would create migrations and apply them with dotnet database update - I even have CI/CD apply the migrations to the prod DB once merged into the main branch.
Overtime however, the database complexity increased; views, stored procedures and functions were created to handle some cases that perform much better by remaining on SQL Server. The problem is the tables are now tracked in a SQL Server .NET Core project as well as in the the code first classes in the business layer of the app. With multiple developers, there is a path that a change made in one project is not reflected in the other. Policy and code reviews are the only gates we have.
What is the recommended approach here? I am currently of the opinion that since we have complex SQL objects such as views, stored procedures, function, etc... that we should treat the SQL Server Project as the source of truth and scaffold the EF classes but that fundamentally, the source of truth should be the SQL Server project and its changes should be applied to the database using Flyway or LiquidBase.
Yes. Code First design workflow is inappropriate when the database has significant SQL artifacts other than tables, or when the database design is performed by team members without .NET and EF expertise.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I'm hoping for some opinions on the best options for how to replicate, in real time, data from a production SQL Server database onto another SQL instance. This second instance would be for vendors who need to access some of the tables from the production database, but we would prefer that they not directly access our production instance.
I have some awareness of transactional replication and log shipping as possible solutions, but I would be interested in pros/cons of these approaches, or superior alternative solutions you may have tried.
I realize there are many topics already on Stack Overflow that discuss how to do this, but many that I found were older (technology's always changing), or focused on a very specific scenario.
For read-only access you can use AlwaysOn Availability Group feature introduced with SQL Server 2012
Documentation:
https://learn.microsoft.com/en-gb/sql/database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server?view=sql-server-ver15
https://learn.microsoft.com/en-gb/sql/database-engine/availability-groups/windows/configure-replication-for-always-on-availability-groups-sql-server?view=sql-server-ver15
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I have few tables that I have to sync between 3 different RDBMS systems (PostgreSQL databases, a SQL Server and a Firebird Database).
Currently I simply connect to my Firebird database and pull the few relevant tables to my PostgreSQL database, but as databases change, new tables require querying and with the addition of a SQL Server database to the mix I feel this solution is ill fitting.
I've done some research on BI tools , but I still need to query data from this data source and show them inside a Windows Forms application.
PS: it's not a migration and I only need to query the data from these "satellite" databases
Using PostgreSQL as your hub, you can use Foreign Data Wrappers to reach out to the other two databases whenever a query wants their data. Then it will always be up to date, but performance might suffer compared to actually importing the data. For reaching SQL Server, you can use tds_fdw, and for firebird you can use firebird_fdw. I have never used either one of these, so this is just a starting point.
You could probably pick SQL Server as your hub and accomplish the same thing, it calls them "linked servers" rather than Foreign Data Wrappers, see for example.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
i'm so confuse now to design good architecture for financial transactional system.
For example :
i have some tables :
MSMembers (for provide member profile and username password of member)
TRTransactions (table record all transaction that comes from other host, such as member's host)
MSFees (list for tiering fee related with number of the transaction)
In my opinion, i think i can :
Separated the database for transactional and master data. For example,
DBMaster : MSMembers, MSFees;
DBTransaction : TRTransactions
So my application (my TransactionService not the web), must connect to multiple database, is it effective if my service connect to multiple database?
Or, same with point 1, but i create MSMembers and MSFees in the DBTransaction, so TransacionService doesn't need connect to multiple database.
Please some advise for this case.
Thanks before. :)
There is no reason to go with separate databases unless you are on MySQL (and in which case database means schema in other databases). Additionally it isn't clear why you would separate these into different schemas in the first place. There is really nothing to gain from this unless you want effectively to use different schemata to manage different sides of your application.
So keep everything in one database. Much easier that way, and you can enforce real database constraints (referential integrity etc) between the parts.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
is it better to put different parts of the app in seperate databases or in a single database file. for example putting forum tables in one database file and putting the blogs tables in another db ??
Separate databases probably don't make sense but, assuming SQL Server 2005 or later, I would encourage you to look into using schemas to logically separate these functional areas. See Buck Woody's article SQL Server Best Practices: User-Defined Schemas as a starting point.
is it better to put different parts of the app in seperate databases or in a single database file
Ah - waht exactly do you ask here? Is this about DATABASES or about DATABASE FILES - a database can have many filegroups which each can have many files.
Depends on size and IO requirements. I have seen databases with 28 groups of multiple files each, to optimize the IO bandwidth of the underlying SAN which was limiting every LUN (and that had multiple files per LUN) to 256 outstanding requests.
if you get into higher end requirements, that makes sense. Likely for you it does not, as your working indicates you dont really know databases, and so you wont work on a multi terabyte high end system ;)