Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p><strong>Question 1:</strong> Does anyone have any experience with swapping out one database for another in a large system, and dealing with the implications in code?</p> </blockquote> <p>Yes we tried it. Our customer is using a large MS Access based Delphi client server application. After about five years we considered switching to SQL Server. We analyzed the problem and concluded that swapping the database would be very costly and provide only a few advantages. Customer decided not to swap the database. The application is still running fine and the customer is still happy.</p> <p>Note that:</p> <ul> <li>MS Access is only being used for data storage and report generation. </li> <li>The server application ensures that MS Access is only being accessed on the server. Normal multi-user MS Access applications will transfer large chunks of the Access database over the network - resulting in slow and unreliable database functionality. This is not the case for this application. Client &lt;> Server &lt;> MS Access. Only the server application communicates with the MS Access database. Actually the Server has exclusive access to the MS Access database. No other computer can open to the MS Access database. Conclusion: MS Access is being used as a true RDBMS, Relational DataBase Management System - please no flaming about MS Access being inferior and unstable - it has been running fine for more than 10 years. </li> </ul> <p>The most important issues you will have to consider:</p> <ol> <li><strong>SQL statements</strong>: (SELECT, UPDATE, DELETE, INSERT, CREATE TABLE) and make sure they would be compatible with the SQL database. It's amazing how much all the RDBMS differ in the details (date formats, number formats, search formats, string formats, join syntax, create table syntax, stored procedures, user defined functions, (auto) primary keys, etc.)</li> <li><strong>Report generation</strong>: Depending on your database you might be using a different reporting tool. Our customer has over 200 complex reports. Converting all these reports is very time consuming.</li> <li><strong>Performance</strong>: all RDBMS have different performances in different environments. Normally performance optimalisations are very much RDBMS dependent.</li> <li><strong>Costs</strong>: the costs of tools, developers, server and user licenses varies greatly. It ranges from free to very expensive. Free does not mean cheap and expensive does not always equate to good. A cost/value comparison will have to be made.</li> <li><strong>Experience</strong>: making the best use of your RDBMS requires experience. If you have to develop for an "unknown" RDBMS your productivity will suffer.</li> </ol> <blockquote> <p><strong>Question 2:</strong> Is it worth it to worry about abstracting the actual database from your code?</p> </blockquote> <p>Yes. In an ideal world, swapping a database would just be adjusting the data connection string. In the real world this is not possible because all databases are different. They all have tables and SQL support but the differences are in the details. If you can keep the differences of the databases shielded through abstraction - please do so. Make a list of the databases you need to support. Check the selected database systems for the differences. Provide centralized code to handle the differences. Support one RDBMS and provide stubs for future support of other RDBMS.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload