Easy SQL Server to MySQL Conversion

April 12, 2004 12:37 PM

My coworker has developed an app using the Borland c++ environment and sql server. Basically, it lets a bunch of instructors score a bunch of papers, each of which is identified by a number.

Because of the licensing restrictions of sql server, we want to port this to php/mysql.

Is there a relatively painless (cheap/free/automatic) way to do this, short of rewriting the whole thing?

Thanks, and sorry for such a dull question.
posted by mecran01 to Computers & Internet (7 answers total)

Is there some other reason you want to port it to php and not keep it in c++?
posted by falconred at 1:07 PM on April 12, 2004

Response by poster: Access to free tools and additional assistance once the author is gone. Makes it more easily distributable to other schools without licensing restrictions, IMO. Allows us to host it on a server within our department and have more immediate control. I like PHP.
posted by mecran01 at 1:11 PM on April 12, 2004

depending on the number of concurrent connections required, you may want to consider the MSDE, a scaled down version of SQL Server that is redistributable. Max simulateous connections is limited to 25, and there are a few other restrictions. Instead of a complete rewrite / port. But this is without knowing specifics, you could be using the MSDE already, and don't want to expand to full blown MS-SQL server for cost reason, even though you need more concurrent connections.
posted by Mahogne at 1:15 PM on April 12, 2004

The general answer to your question is, unfortunately, "No, there is not a cheap and easy and painless way to port your app to a totally different platform."
posted by crunchburger at 1:20 PM on April 12, 2004

what crunchburger said.

I've ported applications from ASP/SQL Server to ASP/MySQL - even with the same language I had to overcome the hassle of converting all my SQL Server Views into SQL queries in the actual ASP (as the version of MySQL I used didn't support Views).

I fear there's no quick and easy way for you.
posted by SpaceCadet at 1:39 PM on April 12, 2004

Response by poster: Ok, thanks!
posted by mecran01 at 1:49 PM on April 12, 2004

Depending on your circumstances, it might be worthwhile to consider using postgresql for your database instead of mysql. The primary advantage of mysql is that its quite fast (if your system has heavy usage and non-trivial hardware requirements, mysql will let you spend less money on hardware). The primary advantage of postgresql is that it supports many more features. In my PHP/database development experience, a fair amount of my code is devoted to database integrity- making sure that only logical combinations of data are stored in the database (for example, making sure that the listed author of a bulletin board post also happens to be one of the registered users). Postgresql makes that easier by providing richer "constraints." You can have a "foreign key constraint" that ensures that the values in a particular column must be one of the values in some other column of some other table (this would be excellent for the example above).

Postgresql supports a lot of other logic features, such as triggers (I have a project with lots of kinds of objects that users can create... many of those objects have a "trigger" that fires before any new object is inserted into a table... it makes sure that the stored creator of the object is the current database user, regardless of what value was provided... this is a low-level security feature to prevent someone from impersonating someone else). In general, storing logic that's intrinsic to your data is easier to do in the database, and can make more sense there, and can be much faster to code (especially if you use a point and click interface to postgresql such as pgAdmin). By pulling some of the data integrity logic out of C++/PHP and putting it into the database, you might save yourself significant amounts of time and produce a more secure system.

Unfortunately, postgresql has a significantly steeper learning curve than mysql. For a small project, its likely that the time spent learning your way around postgresql would more than offset the time savings in coding. If your database has fewer than 5 tables, as it sounds like yours does, there's no way this would be faster. But if you do have any other postgre questions, feel free to contact me personally at greg.steffensen AT richmond.edu
posted by gsteff at 7:02 PM on April 12, 2004