A tool for easy online testing and sharing of database problems and their solutions.
What am I supposed to do here?
If you do not know SQL or basic database concepts, this site is not going to be very useful to you. However, if you are a database developer, there are a few different use-cases of SQL Fiddle intended for you:
You want help with a tricky query, and you'd like to post a question to a Q/A site like StackOverflow. Build a representative database (schema and data) and post a link to it in your question. Unique URLs for each database (and each query) will be generated as you use the site; just copy and paste the URL that you want to share, and it will be available for anyone who wants to take a look. They will then be able to use your DDL and your SQL as a starting point for answering your question. When they have something they'd like to share with you, they can then send you a link back to their query.
You want to compare and contrast SQL statements in different database back-ends. SQL Fiddle easily lets you switch which database provider (MySQL, PostgreSQL, MS SQL Server, Oracle, and SQLite) your queries run against. This will allow you to quickly evaluate query porting efforts, or language options available in each environment.
You do not have a particular database platform readily available, but you would like to see what a given query would look like in that environment. Using SQL Fiddle, you don't need to bother spinning up a whole installation for your evaluation; just create your database and queries here!
How does it work?
The Schema DDL that is provided is used to generate a private database on the fly. If anything is changed in your DDL (even a single space!), then you will be prompted to generate a new schema and will be operating in a new database.
All SQL queries are run within a transaction that gets immediately rolled-back after the SQL executes. This is so that the underlying database structure does not change from query to query, which makes it possible to share anonymously online with any number of users (each of whom may be writing queries in the same shared database, potentially modifying the structure and thus -- if not for the rollback -- each other's results).
As you create schemas and write queries, unique URLs that refer to your particular schema and query will be visible in your address bar. You can share these with anyone, and they will be able to see what you've done so far. You will also be able to use your normal browser functions like 'back', 'forward', and 'reload', and you will see the various stages of your work, as you would expect.
What differences are there between the various database options?
Aside from the differences inherent in the various databases, there are a few things worth pointing out about their implementation on SQL Fiddle.
MySQL only supports queries which read from the schema (selects, basically). This is necessary due to some limitations in MySQL that make it impossible for me to ensure a consistent schema while various people are fiddling with it. The other database options allow the full range of queries that the back-end supports.
Versions of various databases that are either older or newer than the current stable release for that product are hosted by Jack Douglas in his server environment. This means that some of the schema building / query execution actions may be a bit slower for these options, as there is more network latency between my web server and his VMs.
SQLite runs in the browser; see below for more details.
What's up with that [ ; ] button under each panel?
This obscure little button determines how the queries in each of the panels get broken up before they are sent off to the database. This button pops open a dropdown that lists different "query terminators." Query terminators are used as a flag to indicate (when present at the end of a line) that the current statement has ended. The terminator does not get sent to the database; instead, it merely idicates how I should parse the text before I execute the query.
Oftentimes, you won't need to touch this button; the main value this feature will have is in defining stored procedures. This is because it is often the case that within a stored procedure's body definition, you might want to end a line with a semicolon (this is often the case). Since my default query terminator is also a semicolon, there is no obvious way for me to see that your stored procedure's semicolon isn't actually the end of the query. Left with the semicolon terminator, I would break up your procedure definition into incorrect parts, and errors would certainly result. Changing the query terminator to something other than a semicolon avoids this problem.
Why are there two strange-looking options for SQLite?
SQLite is something of a special case amongst the various database types I support. I could have implemented it the same way as the others, with a backend host doing the query execution, but what fun is that? SQLite's "lite" nature allowed for some interesting alternatives.
The other option is "WebSQL." This option makes use of the SQLite implementation that a few browsers come with built-in (I've seen it work in Chrome and Safari; supposedly Opera supports this too). This feature was considered part of the W3C working draft for HTML5, but they depricated it in favor of IndexedDB. Despite this, a few browsers (particularly mobile browsers) still have it available, so I figured that this would be a useful feature to grab onto. The advantage over SQL.js is that it is quite a bit faster to load the schema and run the queries. The disadvantage is that it isn't widely supported, and likely not long for this world.
Together, these two options allow SQLite to run within any decent browser *cough*IE*cough*. If someone links you to a SQLite fiddle that your browser doesn't support, just switch over to the other option and build it using that one. If neither works, then get a better browser.
Who should I contact for help/feedback?
There are two ways you can get in contact:
- Email : admin<at>sqlfiddle<dot>com
- Twitter: @sqlfiddle
Who built this site, and why?
SQLFiddle.com was built by me, Jake Feasel, a web developer originally from Anchorage, Alaska and now living in Vancouver, WA. I started developing the site around the middle of January, 2012.
Ramon Roche helped me to get the UI moved to Bootstrap, and just generally helped to make it look a lot better. This has been my first time using Bootstrap, and without his assistance getting started I'm sure it would have been a lot rougher. Thanks Ramon!
How is the site paid for?
Originally, my costs for operating this site were very low - basically, I had a free ride on the cloud hosting environment purchased by my former employer, GeoNorth. However, as I moved on to different employment, I knew I would no longer have this luxury. Fortunately, the site has had enough usage since it's initial rollout to gain a sponsor's interest. So, thanks to the very good folks at SQL Sentry, I am able to cover the costs of running this site.
Sponsorship aside, server memory is still tight and I would like to expand. If you would like to help me run this site, then you have several options to do so. First, you could visit SQL Sentry by clicking on the ad on the bottom of the main page, and try out their products. Second, you can click on the Flattr link at the top of the page and kick me a little micro-donation. Flattr is a new service so I know a lot of people haven't started using it yet; if you're more comfortable with PayPal, and would like to help me out with running the site that way, I'd really love to have your support. My admin at sqlfiddle dot com address is hooked up with PayPal, so please feel free to help me out that way.
One of the biggest contributors I have for the site is Jack Douglas, from dba.stackexchange.com. Jack has provided many of the VPS instances that I'm using to run the non-primary versions of various databases. Thanks Jack!
If you are interested in the fine details of the code behind SQL Fiddle, it is all available on github
What platform is it running on?
This site uses many different technologies. The primary ones used to provide the core service, in order from client to server are these:
|CodeMirror js||For browser-based SQL editing with text highlighting.|
|Bootstrap css||Twitter's CSS framework (v2).|
|LESS css||CSS pre-processor.|
|jQuery js||AJAX, plus misc JS goodness. (Also jq plugins Block UI and Cookie).|
|html-query-plan js||XSLT for building rich query plans for SQL Server.|
|Vert.x backend||Open Source Java-based Application Server.|
|PostgreSQL db||Among others, of course, but PG is the central database host for this platform.|
|Maven devops||Dependency management, backend build automation.|
|Docker devops||VM management.|
|Amazon AWS hosting||Cloud Hosting Provider.|
|GitHub devops hosting||Git repository, collaboration environment.|
This list doesn't include the stacks used to run the database engines. Those are pretty standard installs of the various products. For example, I'm running a Windows 2008 VPS running SQL Server 2014 and Oracle, and various Docker images running the others.