Enterprise Databases

Associate
Joined
14 Apr 2008
Posts
1,230
Location
Manchester
We're on the cusp of expanding our product to include a large database but as developers most people in our office are choosing the engine based on how easy it is to develop for/features.

I have the most admin knowledge and i'm pushing for something which is well recognised/supported - like MSSQL or Oracle.

What DB's do you prefer in your enviroment? if your company decided they wanted to buy 'Application X' would you be happy if it ran on Firebird or another less well known DB?.
 
In a word, no. Oracle / MSSQL is the top rated standard really, below that you choose between MySQL and Postgres which are probably equal but the number of people who dislike MySQL for serious enterprise stuff is surprising. Then again, plenty of serious web companies use MySQL.

Despite it's power I'd avoid oracle unless you have a product targeted on banks, Oracle is an expensive beast and people capable of maintaining aren't cheap either...
 
We run Intersystems Cache, bit more obscure that the usual MSSQL and Oracle, but very fast. I personally wouldnt trust anything on a different platform than those 3.
 
I would expect top level products to support my choice of database (i.e. customer A on Oracle, B on MS SQL) - which, is extra work for developers, but you may narrow your customer base otherwise.

Personally, we look for MSSQL. We are trying to move away from Oracle as we have favourable licensing costs with Microsoft.

I dislike products which don't sit on one of the major platforms.
 
That's pretty much what i thought.

I'm not directly doing the DB development (yet) but i'm fairly sure the access methods we're using mean we can use any SQL based DB without too much hassle.

MSSQL is a good choice because for a small system the free Express edition will be suitable and can run on the same machine as the application. Oracle also has a free edition but i'm not sure how well it works, it is however, cross platform.

Bigger systems will scale accordingly, the usual way a system is sold is such that we supply a whole system - including pre-configured servers but increasingly customers are asking what DB engine is used and server platforms the app's run on etc.
 
You haven't said what your system is doing but bear in mind some options will be better for certain roles, for instance MySQL can work very nicely with memcached for databases with a high read ratio...
 
Well i obviously can't go into a huge amount of detail.... but...

Even in the largest of systems, the number of operations will be in the low 100s per minute so it's not a high performance DB, although i think they calculated it at being up to about 1Tb of data...

I don't think i'd be happy with MySQL (although it does have it's advocates), mainly as i see it as a smallish web DB, even though there is a well-scaled enterprise variant.
 
Place I used to work at used Firebird. Earlier versions were a pain in the ass but it appeared to get better @ v2.
I tried to push MSSQL but the devs wanted to stay with FB, presumably because they'd read it scaled massively well at 50,000 users and 70342TB.

They were SMB developers.
 
I'm not directly doing the DB development (yet) but i'm fairly sure the access methods we're using mean we can use any SQL based DB without too much hassle.
.

Thats true in only the smallest systems. Once you start scaling your application then producing stored procs and using specific features like table partitioning, AS, RS, IS, transactional replication and more; then you will start having code which is targetted at the DB platform.

As someone who has run a medium size software company then i'd advise that the best thing you do is ensure your devs dont put together the data schema and that you consider things like scalability and reporting day one. Its all too easy to build a bunch of "technical debt" which is hard to pay off in future years.
 
I was meaning more the connection/driver basic connection, obvioiusly it's best to exploit the features of one database than make it general to support more, but not as well.

MSSQL is the route being taken i think with perhaps con-current development on Oracle.

Thanks for your help everyone.
 
Interesting thread. I've been doing a lot more database design and administration in the last couple of months at enterprise scale, transitioning from lower size in terms of total row counts and queries per hour. What I've noticed is that mysql is much quicker to teach new starters, and more flexible out of the box (we like the inclusion of regular expressions with regexp). Where Oracle starts to shine is on DBs storing well upwards of 50 million records. Partitioning is nice and easy as is creating indexes, and after you establish a few hints performance is well above anything I've been able to get from mysql, and in reality with a clear picture of an intended schema we be surprisingly agile with oracle.

From a web applications point of view mysql has the advantage of being ubiquitous. Configuring PhP for example for mysql takes seconds (and is often enabled by default) where as Oracle can be more tricky. Even with the client installed on certain platforms we've had really headaches getting PhP to install correctly, and even when we have there have been more teething problems. We have never gone down the MSSQL route, mainly as Oracle is our preferred enterprise product, consistently out performing MSSQL on most of our applications and typically requiring less support.
 
MySQL is more than capable of supporting a 1TB database, it is often misunderstood as to just how powerful it really is, however, this all depends on what exactly your developers will be doing with the databases, are we talking apps in .NET? C# // VB etc, if so SQL Server is definately your best option (although there is always MONO for Linux) - I'm not a big fan of the cost of SQL if you grow above the express edition (Express edition does NOT come with SSIS if you need that) here are some Express edition limitations:

1. Only 1 CPU supported
2. Max 4GB database size (peanuts, though log file size is not counted in this figure)
3. No job scheduling
4. Export // importing not supported out of the box
5. No SQL Profiler

Personally I'd run them side by side, MySQL and SQL Server Express and evaluate the two since the hardware can be used for either most likely, if not virtualise?
 
9 out of 10 databases I see out there are either MSSQL or Oracle.

The other one part are specialist databases such as KDB which a lot of the finance houses use for trading.

Apart from the above I see nada!
 
Back
Top Bottom