Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I hope I don't make myself completely ridiculous, but I'll have to admit that the definition database schema is not 100% clear to me.
I thought it would be some kind of a blueprint for my tables in my database. In terms of entity framework my DbContext would be my 'database schema'.
I began to realize that I am wrong reading this article (suggested in this question), where multi tenancy can be achieved by Shared Database, Separate Schemas.
Can somebody elaborate?
PS: I read this question but that doesn't really answer my somewhat n00bish question...
The general understanding is as was explained in the question you referenced
schema : database : table :: floor plan : house : room
That is a schema is the blueprint for you database, and in that sense you DBContext + migrations could loosely be considered a database schema.
However there is also a second way the word schema is used in databases, and that is as a partitioned set (tenant) within the database. This is usually used for security.
All tables are defined within a specific schema (for example DBO) and when you query you are actually querying against tables in a specific schema hence
SELECT * FROM [database].[schema].[table]
To answer your question there are 2 meanings to this, one is the english language meaning of the word, the other is the actual SQL meaning (which is to do with tenancy)
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 4 years ago.
Improve this question
I have a question: what is the best practice for migrating SQL Server stored procedures to Oracle?
Thanks.
Best is such a fun word.
But.
Oracle SQL Developer has built in translators, including one for SQL Server.
If you capture your data model using the Migration Projects feature, it will take your T-SQL procedures and convert/translate them to their PL/SQL equivalents.
Each translation will need to be verified/approved/tested, of course.
We see somewhere between 60-90% translation success rates, that is, translated procedures being 'good, out-of-the-box.' Results will vary based on the nature of your code.
I talk about migrations, with Sybase ASE as an example, in this whitepaper. The SQL Server scenario would be pretty much the same.
We also have an ad-hoc translator, but it won't take into account your data model.
I can attest from being involved in a large production legacy project, where substantial number of "automated" options had been evaluated - none of them worked, and almost nothing they did could even be used in the 'at least that' manner.
We wasted a lot of time trying to achieve automation, and then ended up converting everything by hand, which took much less when we involved a small team of coders, once they familiarized themselves with both syntax and optimisers.
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 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 2 years ago.
Improve this question
I have been given an assignment to get the feasibility for making a dll which takes some inputs such as database name (Mysql, access, sql, oracle etc.) and some more inputs to generate a query, and based on that the dll should return a recordset to the application.
Is it a good idea? If yes, then what inputs should I consider?
It's completely feasible, the issues arise when you encounter different SQL grammars - take a look at how Hibernate handles this with the use of Dialects.
The popular databases - Oracle, Sybase, MS SQL Server, MySQL - have slight differences in the SQL grammar they allow. Essentually the vendors have implemented and extended ANSI SQL in different ways.
The simplest case I can think of is when the way you assign pseudonyms to column names, some databases require this:
SELECT x AS y FROM some_table
while others require:
SELECT x y FROM some_table
There's many more such examples, but the bottom line is that when writing a query abstraction layer that works across all databases you need to abstract the concept of SQL generation so that it can be tailored to each database you are going to support (as I said, Hibernate does this by allowing you to specify a dialect specific to the database you are using).