MySQL, PostgreSQL, Oracle,...... ?
http://www.cyberciti.biz/tips/mysql-vs-postgresql.html
http://www.cyberciti.biz/tips/mysql-vs-postgresql.html
Which SQL is widely used in finance?
- Thread starter featips
- Start date
- Joined
- 5/2/06
- Messages
- 12,165
- Points
- 273
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.
Just so you know, mySQL is the most popular database powering big websites, including QuantNetwork.
- Joined
- 5/2/06
- Messages
- 12,165
- Points
- 273
I always wonder what those low latency guys use to keep their tick data. I read sometime ago but the name didn't tick.
Time series databases that record the flow of ticks:
Mike Rettig's Weblog : Weblog</title><title>Brushed Metal: It Worked!
Mike Rettig's Weblog : Weblog</title><title>Brushed Metal: It Worked!
- Joined
- 5/2/06
- Messages
- 12,165
- Points
- 273
That blog was from Sept 2006. I wonder if there are newer, more efficient way to do this.
- Joined
- 1/16/08
- Messages
- 19
- Points
- 11
In overall finance - Sybase, Oracle as fas I know.
I thought so too that they predominantly run databases on top of UNIX/Linux servers - Oracle, Sybase, and maybe MySQL.
- Joined
- 4/16/08
- Messages
- 394
- Points
- 28
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.
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.
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.
alain
Older and Wiser
- Joined
- 3/29/04
- Messages
- 2,767
- Points
- 93
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).
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.
- Joined
- 4/16/08
- Messages
- 394
- Points
- 28
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.
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.