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).
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 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
We work to study database types.We found one of types is MPP databases. What is mean MPP Databases?, and are Oracle and SQL Server one of these databases, specifically we can create data warehouse schema ,if the MPP databases are data warehouse ?
In this context, I believe that MPP standard for "massive parallel processing".
When this term was invented, it referred to any database (or software architecture) that was scalable in hardware. This includes the ability to increase the number of the disks and processors arbitrarily -- although restructuring the data might be necessary.
Originally, databases such as Oracle, Teradata, Tandem, and DB2 were examples of MPP databases. SQL Server now has a scalable architecture, so I would put it in this category as well.
I do think that newer technologies, such as Google BigQuery are more scalable than even these products (although that might be verging on opinion).
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 details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I heard, that it is possible to speed up SQL Server by writing all the scripts in one case (UPPER or lower) and turning on special option, that tells Server, that all the commands written in one case.
Is it right? If so, how many benefits it gives? Thanks.
I didn't hear something like that. I think, it's a joke or legend :)
No, definitely not.
There are a couple of related things that might have contributed to this strange claim/rumor:
By default SQL server names are not case-sensitive, but you can set this option at the database level by choosing a case-sensitive collation like "SQL_Latin1_General_CP1_CS_AS". This will make all database object names case-sensitive, but it has no effect on SQL keywords like "SELECT". Note, it will also cause table collations to be case-sensitive by default, so text comparisons will also become case-sensitive unless you choose another collation at the table or comparison level.
It is good practice to specify the object schema in your SQL statements (eg "dbo.SomeTable" instead of just "SomeTable"), and this provides some small performance benefit as it can save SQL server from needing to look for the same object in multiple schemas.