http://www.codingthearchitecture.com/tags/sql/ Software architecture for developers en Coding the Architecture Mon, 21 May 2012 09:41:00 GMT Pebble (http://pebble.sourceforge.net) http://backend.userland.com/rss http://www.codingthearchitecture.com/2009/07/21/to_sql_or_not_to_sql.html <p> Eric Lai wrote an interesting article for Computerworld entitled <a href="http://www.computerworld.com/s/article/9135086/No_to_SQL_Anti_database_movement_gains_steam_">No to SQL? Anti-database movement gains steam</a> that highlighted the small but growing trend for not using a traditional relational database for managing data. Nati Shalom's <a href="http://natishalom.typepad.com/nati_shaloms_blog/2009/07/no-to-sql-anti-database-movement-gains-steam-my-take.html">No to SQL? Anti-database movement gains steam - My Take</a> is a good follow-up. </p> <p> I'm sure that most of us have good experiences of using a relational database in our projects and, despite the pain of sometimes mapping the data into a relational schema, relational databases provide an easy to use known quantity for managing data. With this in mind, you should certainly let your <a href="http://www.codingthearchitecture.com/2008/07/30/experience_should_guide_not_constrain.html">experience guide you</a> but bear in mind that relational databases aren't the answer to every question. </p> <p> The case study that we use as a basis for the <a href="http://www.softwarearchitecturefordevelopers.com">exercises in our software architecture training course</a> is relatively small yet most people decide to use a relational database to store the data without really giving the alternatives a second thought. Most of the time it comes down to experience in that most people are comfortable with using a relational database in their architecture. But there are many viable alternatives; from using flat files and object databases through to in-memory data structures, data grids and the cloud. So while relational databases might be a solution for your particular problem, it's always worth spending a couple of minutes assessing whether they are the *best* solution. Here are some things to think about before deciding on whether to go down the SQL or non-SQL route. </p> <ul> <li>Do you have special non-functional requirements that would be hard to satisfy with a relational database? (e.g. high performance/low latency, massive scalability, etc)</li> <li>What is the available skillset of the team?</li> <li>Do you have existing licenses for an RDBMS?</li> <li>Could an open source RDBMS be appropriate?</li> <li>Do you need to access legacy systems where the data is already in an RDBMS?</li> <li>Do you have the hardware available to run an RDBMS?</li> <li>Do you already have existing backup and archival processes and procedures for relational databases?</li> <li>What are your management information and reporting requirements (scheduled and ad hoc)? Is it possible to satisfy these with a non-SQL solution?</li> <li>Do other systems need access to your data via a SQL interface? (a service gateway might be a better approach, but that's another issue)</li> <li>Do you have data migration requirements from an existing relational database?</li> <li>Can the data management problem be split up into transactional and non-transactional partitions, maybe using a relational database for only one of them?</li> <li>Do you really *need* persistence?</li> </ul> <p> Relational databases are established mainstream solutions that are applicable in many cases. Just don't forget that there are other alternatives too. </p> How do you define software architecture? http://www.codingthearchitecture.com/2009/07/21/to_sql_or_not_to_sql.html#comments http://www.codingthearchitecture.com/2009/07/21/to_sql_or_not_to_sql.html Tue, 21 Jul 2009 10:07:00 GMT