1) Is there MongoDB-to-Postgres Translation layer? 2) Is there converter that can convert schema and transfer all data from: 2.1) MongoDB to SQLite? 2.2) MongoDB to PostgreSQL?
Babelfish: SQL Server-to-Postgres Translation Layer
101–110 of 118 posts
Re: Babelfish: SQL Server-to-Postgres Translation Layer
#102Don'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.
For SQL server, AWS can save their customers money by cutting license cost (to MS). MySQL is already free so I don’t see how they can benefit from such a project.
They can go one better — they can fork the parsers out of both projects and run it against a common query planner/storage engine (aurora).
Re: Babelfish: SQL Server-to-Postgres Translation Layer
#103Earlier quoted context omitted.
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 o…
MySQL has worse guarantees in several cases, though. For example, using `SERIALIZABLE` isolation means your queries can deadlock when run in parallel. Likewise, selecting a column not present in a GROUP BY leads to random values being returned.
> Likewise, selecting a column not present in a GROUP BY leads to random values being returned.
That hasn't been the default behavior for something like 5 years.
Beyond that the values aren't "random" as much as "one of the values from the set" which can be a useful feature in cares where you want any of the values and don't want the performance hit that comes with using an aggregate function particularly on very very large sets.
Re: Babelfish: SQL Server-to-Postgres Translation Layer
#104Don'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.
For SQL server, AWS can save their customers money by cutting license cost (to MS). MySQL is already free so I don’t see how they can benefit from such a project.
>don’t see how they can benefit from such a project
I thought there were bad blood between Oracle and Amazon?
Re: Babelfish: SQL Server-to-Postgres Translation Layer
#105Ancient muscle memory completes the URL thusly:
babelfish.altavista.digital.com
Re: Babelfish: SQL Server-to-Postgres Translation Layer
#106Earlier quoted context omitted.
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.
Exactly that. It's a nightmare to maintain but business types seem to demand it.
I used to work at big hospital that had a home-grown 'reporting system' built with Excel, data connections to an SQL Server database, and a series of pivot tables. Every morning from 8-9am the whole network would slow as people opened their spreadsheet and it basically did a `select * from a_rather_large_view` - tens of gigabytes flying around (this was in the mid 2000s.)
There was resistance after a data warehouse (BO) was introduced because pivot tables were so flexible and well-understood.
Re: Babelfish: SQL Server-to-Postgres Translation Layer
#107Re: Babelfish: SQL Server-to-Postgres Translation Layer
#108> A commonly used datatype to store monetary values is the MONEY data type. In SQL Server, the MONEY data type’s behavior is fixed using four digits to the right of the decimal (e.g., $12.8123). However, in PostgreSQL, the MONEY data type is fixed using two digits to the right of the decimal. > So, when the application tries to store a value of $12.8123, by example, PostgreSQL will round to $12.81. This subtle differ…
> How are they going to solve this with just a query translation layer? Well, the translation layer isn't just a query (DQL) translation layer, its an SQL Translation layer including DDL, DML, etc. Since both Postgres MONEY and SQL Server MONEY are 8-byte, fixed-precision decimal types, with the only difference being the position of the implicit decimal, a translation layer can use one as the backing store for someth…
One can also change the precision of psql's monetary type. From the docs:
> The fractional precision is determined by the database's lc_monetary setting.
Re: Babelfish: SQL Server-to-Postgres Translation Layer
#109Earlier quoted context omitted.
Correct. The focus is on 100% correctness. As I wrote in the post: "Over its 35 years in existence, SQL Server has evolved to meet a wide array of use cases. When first made available on GitHub, Babelfish won’t be able to handle every use case, but will be able to tackle the most common application scenarios. Most importantly, Babelfish will meet the correctness objective. That is, if Babelfish doesn’t yet support sp…
Interesting. Now where's the Oracle-to-Postgres Translation project? ;-)
Some time ago there was big news about Amazon migrating away from Oracle. Related to this?
Announcing this first for SQL server might be a way to launch softly and learn.
Re: Babelfish: SQL Server-to-Postgres Translation Layer
#110As 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?
Postgres is functional by default, no need to throw asinine "with (nolock)" hints on every join.