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.
Related
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 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.
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 8 years ago.
Improve this question
I have written a project in C# which currently uses a SQLite database with 7 tables. Now I made a little mistake in selecting my database and since the application is going to be accessed by multiple users (~100) on a network the SQLite solution won't work because only one user can write at a time.
Now I want to switch to an Access (2010) database but my question is:
If I create the Access database with the same scheme as my SQLite database, do I have to change any of the SQL statements that I have written in my application? Or does this work interchangeable?
Also some side notes of why I am switching to an Access database instead of something like a SQL Server... Time does not allow this and costs neither.
Does anyone know what the impact will be if I'd simply replace the SQLite database with the Access database. And are there any differences in the SQL for these two for simple queries? I'm using things like 'INNER JOIN, IS NULL, SUM, COUNT'.
Thanks in advance!
are there any differences in the SQL for these two for simple queries?
For the simplest of queries, not really. For example, the specific language features you mentioned (INNER JOIN, IS NULL, SUM, COUNT) will likely work without modification, with the possible exception that Access SQL often requires parentheses when a statement contains multiple JOINs (example here).
Does anyone know what the impact will be if I'd simply replace the SQLite database with the Access database.
That is impossible to predict without a complete code review. You will really just have to try it and see what (if anything) breaks.
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 8 years ago.
Improve this question
I'm newer to Postgres, having used MySQL almost exclusively in the past I'm looking to move to Postgres for its more enterprise like features and SQL compliance. However Postgres is structured much differently than MySQL in the since that you have a database and then one or multiple schemas under it, while in MySQL database and schema are kind of one in the same. In terms of best practices should my application is Postgres be one database and one schema? Or is it okay to split tables into logical groups as schemas. Example the user_management schema would include the user, role, role_map tables, etc.
I realize this question is highly subjective but I'm just looking for best practices. My database at this time only has 40 tables so I'm a little wary about using multiple schemas to group tables logically since some would have just a few tables. I'm just not sure what people are doing with Postgres in the real world.
It's almost always going to be better to keep them in a single schema and put that as the first schema on the search_path for the user/database. Many people just use public, and that's fine. It's also quite reasonable to name a schema after your app and keep your tables in that.
Some tools aren't schema-aware, or make working with schemas harder. So if you don't need the namespacing schemas provide you may reasonably choose not to use it.
For re-usable components you'll likely want to package them as trivial SQL-only extensions (see writing extensions, in which case there's no need to isolate them in a schema.
I mainly see schemas as useful when you need namespace isolation - for example, allowing different apps that might have conflicting table names to share one database, or as one of several approaches for multi-tenant application instancing.
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 ;)