To Change Data Platforms, You Need to Convert Your SQL
You’ve decided to change from your legacy data platform to a shiny new one.
The POC went well. The vendor is showering you with credits, love & affection (obvs).
Plans are in place to migrate the data.
Which leaves SQL conversion. It doesn’t look too hard, right? Especially with our SQL Conversion Tool.
Standard SQL Doesn’t Exist
“But what about ANSI-standard SQL?“
No vendor supports the entire SQL standard. Fact.
All SQL Dialects Are Different
Even the humble ‘SELECT’ can be truncated to just ‘SEL’, and ‘DELETE’ to ‘DEL’.
Looking at you, Teradata.
Your SQL Won’t Work Elsewhere
A lot of your existing SQL will work elsewhere.
But that’s not good enough. It all needs to work.
SQL Conversion Is Not Easy
But it’s just a ‘search & replace’ challenge, right?
Well, kinda. But then it gets tough. Really tough.
We couldn’t find an SQL conversion tool we liked… so we built our own.
Our SQL Converter Is Built by SQL Experts
There is only one way to convert SQL to run elsewhere: properly.
Each statement needs to be inspected, decomposed & converted if required.
The new SQL also needs to look & feel as close to the legacy SQL as possible.
Let’s not ‘frighten the horses’ as one of our clients likes to say.
1
No access required to source system. Only inputs are metadata and source SQL (DML & optionally DDL).
2
Target schema created by converting source DDL or from metadata unload.
3
Code audit provides quick insight into % of SQL that needs conversion.
4
Multi-stage process to convert SQL code including semantic query decomposition.
5
Conversion rules engine easily extended with client-specific edge cases.
6
Source SQL code changed as little as possible to honour existing coding style.
Frequently Asked Questions (FAQ)
Which Source SQL Dialects Are Supported?
Due to client demand, we’ve started with Teradata as the first legacy SQL dialect. It’s also one of the hardest with all those pesky abbreviations, BTEQ commands, implicit CASTs and proprietary SQL extensions. Thankfully, we’re Teradata experts.
Which Target Dialects Are Supported?
So far we’ve tested against Postgres, Greenplum and Snowflake as target SQL dialects.
What’s Needed To Get Started?
There are only two main requirements to get started.
First, we require either golden source DDL or a metadata unload from the system catalogue. This is used to create the new/target schema.
Second, we need the SQL to be converted. All the objects referenced in the DML must either be ‘inline’ or be covered in the DDL/metadata already provided.
How Long Does Conversion Take?
The initial audit/conversion process usually completes on the same day. This includes building a new/target schema against which each SQL statement is tested.
Will All Of My SQL Be Converted?
We aim to convert as much of your legacy SQL as quickly as possible. Any statements that fail conversion are typically client-specific edge cases. These are then analysed, used to update the rules engine and re-processed.
What’s The Charging Model?
There are several charging models available. Importantly, you’ll only pay us once to convert your SQL. There is no ongoing ‘cost of carry’.
Why Don’t I Just Pay An Outsourcer?
The ‘caffeine & keyboards’ approach to SQL conversion has several drawbacks:
- cost
- timescales
- code variability
Try VLDB’s SQL Converter.
Unlock seamless SQL conversion with our cutting-edge converter!
Elevate your database management experience and save valuable time.