Earlier quoted context omitted.
Interesting. Now where's the Oracle-to-Postgres Translation project? ;-)
isn't that what enterprisedb is selling ?
Yes but it isn't Open Source.
Babelfish: SQL Server-to-Postgres Translation Layer
41–50 of 118 posts
Re: Babelfish: SQL Server-to-Postgres Translation Layer
#42Don't hate me for it, but I'd like this for MySQL to postgres too. At least as a stepping stone. Use case: some of my SQL syntax depends on MySQL but I realize I made a poor life choice and would rather have transactional DDL and a myriad of better features on postgres.
You might be able to get away with staying with MySQL or a variant. Years ago I did an "interview problem" to generate a report of some accounting data of a sample data set in MySQL. The details are foggy now, but I ended up doing it all using advanced SQL features that I thought only existed in PostgreSQL (you know, or Oracle), but whatever engine I ended up using had it as well. It was probably the latest Percona or Maria?
Re: Babelfish: SQL Server-to-Postgres Translation Layer
#43Don't hate me for it, but I'd like this for MySQL to postgres too. At least as a stepping stone. Use case: some of my SQL syntax depends on MySQL but I realize I made a poor life choice and would rather have transactional DDL and a myriad of better features on postgres.
However if the translation layer is designed for consistency, like Babelfish, it would have to replicate many of the MySQL “faults” too... e.g. it would need to have the same non-transactional DDL so it acted “correctly”! And it would need to replicate the specialised data types like utf8mb3. To use PostgreSQL features (such as JSON datatype) would presumably need a separate data connection and transaction, because i…
It would be nice if it could aim for doing the sane thing over exact MySQL compatibility. But I agree it would be a minefield...
Re: Babelfish: SQL Server-to-Postgres Translation Layer
#44This is interesting because it will also help Sybase migrations. SQL Server is the "brand name" but there are still a lot of people stuck on Sybase.
Will it? MSSQL and Sybase diverged somewhere around 27 years ago; anything that Sybase and Microsoft did differently since then would likely be completely incompatible.
Re: Babelfish: SQL Server-to-Postgres Translation Layer
#45Why not do this for Oracle? I've not found SQL Server to be too bad from the crazy Oracle stuff (light experience only - maybe bigger players have it worse?).
About 10 years back my company hired consultants, spent close to 6 months translating SQL queries/stored procs to be Oracle. The goal was to support both MSSQL Server & Oracle for the on-premise product. It was quite costly undertaking. Then few years later they just abandoned Oracle because of maintenance costs. I wonder if anyone starting out today chooses Oracle as their relational database.
> I wonder if anyone starting out today chooses Oracle as their relational database.
Your boss does.
Re: Babelfish: SQL Server-to-Postgres Translation Layer
#46This is great. I suspect that I have exactly the right use case for this.
The two main issues with running SQL Server are (1) you have to license all the cores on a system and (2) the standard license only recognizes up to 64GB RAM. So I actually wound up buying a 3GHz single-socket system for around $10K to save $20K on the SQL license.
With this, I can move a couple of the big DBs to another system that has 32 Cores with 256GB RAM and the entire DB will fit in memory, put in 5GB ethernet, and gain a tremendous amount of performance.
But, more importantly, I can migrate the workload on a case-by-case basis. Human costs always dwarf my software and hardware costs.
Re: Babelfish: SQL Server-to-Postgres Translation Layer
#47As someone who has been fighting with a SQL Server to Postgresql conversion this sounds AMAZING. Too bad it won't be available before my conversion is complete (and if it is, that's an even sadder proposition)
Out of curiosity: besides cost, are there other significant reasons that drive your desire to switch?
I guess it's linked to cost but the pure painfulness of just having licensing in the way of your infrastructure management is pretty annoying.
We literally have had this problem the last few months where we had a spike in load causing wide spread performance issues and the obvious answer was to give the server more cores but "we're not licensed for that" ... so everybody just suffered through it because temporarily giving the DB more cores for a few hours was just too painful / costly from a licensing point of view.
Re: Babelfish: SQL Server-to-Postgres Translation Layer
#48Why not do this for Oracle? I've not found SQL Server to be too bad from the crazy Oracle stuff (light experience only - maybe bigger players have it worse?).
I bet they are working on it.
Re: Babelfish: SQL Server-to-Postgres Translation Layer
#49Why not do this for Oracle? I've not found SQL Server to be too bad from the crazy Oracle stuff (light experience only - maybe bigger players have it worse?).
About 10 years back my company hired consultants, spent close to 6 months translating SQL queries/stored procs to be Oracle. The goal was to support both MSSQL Server & Oracle for the on-premise product. It was quite costly undertaking. Then few years later they just abandoned Oracle because of maintenance costs. I wonder if anyone starting out today chooses Oracle as their relational database.
Oracle is very powerful. As a developer I found it easy to work with. But the cost to run in production is eye-watering. IDK how their licensing works today but in the past it was free to use for evaluation or for developing a prototype. Once you were "gaining business value" i.e. using it even if only internally to develop a real product, you were supposed to be paying for it.
Re: Babelfish: SQL Server-to-Postgres Translation Layer
#50Earlier quoted context omitted.
What does “connect” mean in this context? Read data from SQL server into an excel spreadsheet?
Not the GP but yes I've seen a lot of folks go through the Data tab in Excel and connect to a SQL database to display data directly.
Excel can connect to PostgreSQL as well.