• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

Which SQL is widely used in finance?

MS SQL, followed by mySQL. Big firms use mostly MS SQL while smaller shops may favor free, open source mySQL. Syntax is mostly similar though things are called differently and the data structure is different. Unless you want to become DBA, it's of less importance.

Just so you know, mySQL is the most popular database powering big websites, including QuantNetwork.
 
Not essentially a 'newer' way, but kdb+ is the standard for tick data in a lot of the equity houses.
 
Two following questions:

(1) Looks like MS SQL server is popular, but that is only limited to Windows, right? I thought lots of financial companies are using Linux/Unix....

(2) How is PostgreSQL used in financial industry?
 
Two following questions:

(1) Looks like MS SQL server is popular, but that is only limited to Windows, right? I thought lots of financial companies are using Linux/Unix....

I thought so too that they predominantly run databases on top of UNIX/Linux servers - Oracle, Sybase, and maybe MySQL.
 
A big bank will use all of the enterprise databases. In order I would say: Oracle, DB2, MS SQL, Sybase
If the question is focused on tick-data, then I think RRD solutions (KDB or others) backed on disk are still a good option.
 
Sybase definitely seems like it's on its way out, right now. I work for a UK-based universal Bank whose investment banking headquarter's is in New York, and we're in the process of phasing out Sybase in favor of Oracle, along with a number of other investment banks. We also employ some XML databases, too- so don't forget your XPaths, XQueries, and XSL Transforms.

That said, there's really only minor syntactic differences between different relational systems on the surface. I'd recommend staying focused on SQL first, and second off, focusing on the fundamentals- the different kinds of joins and the benefits of indexing. You can learn some of the semantics like storedprocs in an hour or two, but if you learn the standard, that carries everywhere. In reality, most developers will be able to get some help from DBAs in optimizing their most expensive queries, and I wouldn't put SQL on the top of the priority list for a typical quant developer.
 
from my experience, every database is used out there. From Oracle, Sybase, MySql, MS SQL, Postgress and DB2 to more esoteric ones like KDB and column oriented databases (very good to stored and operate time series data).

Sybase is not on the way out, they have a product that they market specifically to the Financial industry (I think it's called Sybase IQ).
 
from my experience, every database is used out there. From Oracle, Sybase, MySql, MS SQL, Postgress and DB2 to more esoteric ones like KDB and column oriented databases (very good to stored and operate time series data).

Sybase is not on the way out, they have a product that they market specifically to the Financial industry (I think it's called Sybase IQ).
All I know is that our CIO hates them and it is my understanding that the guys across the street (Morgan Stanley) hate them, too. My friends at Markit say it is also being phased out there.

Bottom line: Sybase sees its customers as a cash cow, and the customers are tired of getting milked.
 
I also hate Sybase, Oracle, MS SQL and DB2 too. So we are on the same boat. They all charge an arm and a leg for their product.
 
I also hate Sybase, Oracle, MS SQL and DB2 too. So we are on the same boat. They all charge an arm and a leg for their product.

DB2 or SQL Server have some powerful features. I've seen/updated stored-procedures same as source code with several hundred lines. They were primarily used to aggregate tables from different databases with completely different functions (e.g. inventory data, monitoring data, server information, application configuration).
The complexity was not really needed in many cases, but it was just added optimization (e.g. multiple layers of cursors).

In the end, optimization options for each database type can be learned on the job. GoIllini is correct, understanding SQL is sufficient at interview stage (unless you apply for a DBA position)
 
DB2 or SQL Server have some powerful features. I've seen/updated stored-procedures same as source code with several hundred lines. They were primarily used to aggregate tables from different databases with completely different functions (e.g. inventory data, monitoring data, server information, application configuration).
The complexity was not really needed in many cases, but it was just added optimization (e.g. multiple layers of cursors).

In the end, optimization options for each database type can be learned on the job. GoIllini is correct, understanding SQL is sufficient at interview stage (unless you apply for a DBA position)
I would also throw in that for some interviews it could be helpful to know some of the generic implementation details in the abstract common across all systems for some development interviews. (IE: Indices, stored procs). In a more development-specific interview, a question may come up like, "Why do developers use stored procedures? Why not just run the query as SQL from the system?" Or, "Let's take a look at this question again, but assume this time that we have an index set up on this column. How would you change your query to take advantage of that?" You don't need to be an expert on the specifics of a database, but if you can reason your way through these questions in the abstract, it will look good in an interview.

Don't waste your time on this for a quant development interview unless they specifically say a knowledge of SQL is good. That said, some SQL knowledge is expected for general financial programmers and these may come up as a follow-up "bonus" question if you do well on the basics of relational databases. It is practically impossible- even on Wall Street- to find someone with everything from communication skills to stochastic calculus to product knowledge to development skills who also knows SQL like the back of their hand.

MySQL, PostgreSQL, Oracle,...... ?

My view is that a quant developer really isn't expected to know SQL by heart. A general financial programmer like me is expected to have a well-rounded skill set in algorithms, language, data structures, threading, financial products, business knowledge, and some databases. For a quant developer, the SQL and threading parts often become less central to the position, and the financial products and business knowledge get more important- with an added item: financial modeling.

Typically, financial developers like me will be building a less proprietary bond calculator around the proprietary pricing engine that quant programmers create and we don't get the source code for. We'll be the ones doing the SQL queries, and passing the data directly into the quant developers' code. So for a quant developer, the database stuff is abstracted in many cases.

If you want to be a quant developer, keep focusing on pricing models, financial products, algorithms, data structures, and communication skills (as well as mental toughness if you want to work with traders). SQL may be a minor selling point in some cases, but it's not the staple of a quant developer; that's usually product/pricing knowledge and development skill.
 
Back
Top