One of the choices a customer interested in Microsoft Dynamics NAV must definitely make is the choice of the database platform. With NAV, there are two possible options: so called native database server, which is not really officially called that (the official name is Microsoft Dynamics™ NAV Database Server), and Microsoft SQL Server.
I’ve scratched the surface of topic of database options in Techno stuff, but I decided to delve a little bit deeper into details. Elaborating a little bit wouldn’t hurt anyone, but could help those in doubt. What I am going to make is a series of posts about these two database options, which I hope could help those interested to understand the real differences between them. I’ll try to give a little bit of history of the system and its evolution, why it was only one database option, and why it came to be two of them. I’ll do my best to make it as factual as possible, but there will be a lot of my personal conclusions and views, so please take it with a grain of salt, and please feel free to point out anything that might not be exactly true.
Microsoft Dynamics NAV Database Server is a proprietary database platform, developed by Navision A/S almost twenty years ago, with sole purpose of supporting a growing new accounting software called Navision. Unlike commercial database platforms, it wasn’t ever intended to compete with the giants, or to become a public relational database management platform. Its design went hand in hand with the design of Navision, the accounting application, and its evolution was driven by the evolution of Navision. Since Navision was initially targeted primarily at smaller, and to an extent also mid-size companies, scalability was low on the list of issues the development team had in mind. With only a handful concurrent users usually requiring access to the system, one of the main targets was performance at the targeted concurent user count, and Navision Database Server was always up to the challenge.
However, along came the growth. It wasn’t only the growth of the market share of Navision software, and the growth of the interest in it, it was also an ever increasing growth of overall penetration of information technology into business. Companies wanted to cover more and more business processes in their systems, bringing computers to employees who never before had access to them, so even if the target market for Navision didn’t shift towards bigger companies, the needs of the same-size companies increased dramatically over time. Companies which once needed only a handful of concurrent users, now had real needs for several dozens of them. What was small, grew bigger, and over years, from version to version, Navision was steadily getting the shape of a true ERP system. Scalability became important.
New millennium was poised to bring new trends. Revolution of BI systems in late nineties emphasized the necessity of data integration even for those companies that never had similar needs, which together with scalability much higher in the list of priorities contributed to the fact that Navision had to expand its support for other database systems. Since Navision was always run on Microsoft operating systems, logical next step was to support Microsoft SQL Server. This was a strategic move. In 1999, Microsoft SQL Server 7.0 was an emerging platform, the first serious database management system Microsoft pushed to market to that point, bringing tons of improvements over its predecessors, and promising a lot in many areas, including scalability, data warehousing, and OLAP soon to follow. Companies who would invest into SQL Server expected returns not only from it supporting an ERP system on top of it, there was much potential in other areas as well. Navision Database Server was experiencing increasingly more problems in the field of scalability, struggling to meet the needs of companies who were approaching hundred concurrent users, while at the same time SQL Server 7.0 could support hunderds or even thousands of concurrent users without a flinch. If Navision failed to support SQL Server at that strategic moment, their customer base would soon shift to other vendors, offering their products on top of SQL Server or other standard database platforms of the time. So was born a new database option for Navision: Microsoft SQL Server option.
But scalability of SQL Server alone wasn’t the only answer to concurrency issue of Navision Database Server. Concurrency problem of Navision Database Server was in architecture of the system as a whole, rather than just in the scale-up capabilites of the database platform. As a fat-client two-tier system, application logic was executed at the client, and two major factors contributed to the low concurrency: amount of data locking, and transaction duration. With database cursors and table locks all over, and transactions taking up to several seconds, there wasn’t really much to be done with the concurrency. With tens of users attacking the same tables, timeout was a new domestic animal in the yard.
SQL Server could address this issue only to an extent, and while the customers who decided to dogfood on the new platform choice did indeed benefit from its many advantages, scalability wasn’t one of them. While it really did scale better than Navision Database Server option, the progress wasn’t as dramatic as would be expected from the benchmarks SQL Server achieved with the products which were designed to leverage on its scalability capabilities. Navision Database Server could still cope with few tens of users, but the limit was usually percived to be somewhere in 40-50 range. SQL Server hardly scaled to 100, which was better, but not that good. Thus Navision earned its stigma of a system for small companies.
Few years later, Microsoft acquired the Navision A/S, and things started changing for better.
I leave it at this for today, it is a little bit late, and I am a big bit tired, and then, why not leave something for tomorrow. Go read other blogs, then come back later for description of the differences between these two options, and how the old dog learned new tricks, because when Microsoft got hold of Navision, not only the name changed, but much, much more.
