Hello! I just started a company and we are in the stages of choosing our database (we have yet to hire a dba/architect). Right now, being a start-up, we lack the money to purchase any big license so were thinking of going with mysql or postgres (we are leaning towards mysql). My question is that if we start off and create the architecture for mysql, later on, if we want to move to something like SQL Server 2008 or Oracle, what is involved? Would be have to redesign the architecture? I'm assuming we cannot have stored procedures that create the tables in mysql and use the same in SQL server or oracle, and then import in the data. I'm not a very technical person, but I will be in touch with one of my developers regarding this post, so all the information/recommendations you can give me would be great.

Thanks!

It really depends on what the application has to do and how it is implemented. For example, what is the architecture going to be, are you going to be developing using PHP with the database on the same local machine or on a separate machine. Using stored procedures can speed up database processing if you want to include the business logic in the database. However, if you use something like ODBC connections you can change the client to point to any type of database provided your SQL statements are written correctly. The benefits allows the solution being developed to be portable with minimal changes but overall performance might not be sufficient for the application.

Hope this helps?

You should take a look at DB2 Express-C. It's fully functional and free. It's also 100% compatible with all other versions of DB2 so if you choose to upgrade to another version of DB2 in the future you won't have any problems.

IBM - DB2 Express-C

There is truly no such things as a free lunch, although MySQL and Postgres come pretty close. The free editions of DB2, Oracle, Sql Server are limited in various ways, some on function nearly, probably, all on the number of concurrent users you can have. If you sell an application that uses MySQL then you (or the end user) have to have a licence, thats alwyay been the MySQL policy

if you think you are going to go down the Oracle or SQL server route then Id seriously investigate whether one of their limited editions will work for you and develop for that from day one.

If not then you may have to use mySQL or Postgres, but make certain you develop your SQL using ANSI standard SQL not one of each manufacturers variants. you could do this by developing in say MySQL, but testing each SQL statement against one of the limited SQL Server /. Oracle / DB2 / whatever installations to make certain your code is portable. Of course another option is to develop your code in such a way as it runs on whatever database engine you or your customers need by sub classing the actual db interaction into separate implementations, so there would be no SQL interactions in the main code, the SQL would be in a separate module for each db engine.

there are many tools that will shuffle data and table metadata between the various engines, however as far as i know there are no tools to push triggers and stored procedures between data engines, not least because the table design metadata is fairly standard, whereas each company has rolled their own versions of SP's and triggers. however if you do a proper design approach and thoroughly document what you are doing and what each SP / trigger / physical design choices you are making then the process is manageable.

personally I think it would be madness to develop in MySQL with an intention to switch to SQL server or Oracle at a later date. I could understand if say you wanted to support Oracle & SQL server at a later date but not one or t'other. if you know you will only target one platform then target that platform from day one