Embedded vs. In-Memory vs. Server Databases

Software developers often interact with server oriented databases. However, there are at least two other types of databases, embedded and in-memory, which are less known to the software developer community. Here are the three types I would like to broadly classify the databases into:

a) Server Centric: They usually require a separate installation of the database server component. These are the most common types of databases, for example, SQL Server, Oracle, MySQL, Postgres, DB2, and so on. The database engine of these databases are hosted in a separate process. The applications trying to access data in these databases need to first connect using a database connectivity technology such as ODBC, OLE DB, ADO.Net, etc., and then execute SQL commands. The actual execution of the SQL queries are performed by the database engine.

b) Embedded: These databases do not require installation of any database components; often they are called as server-less or embedded databases. Some examples are SQLite, Firebird, MS Access, Derby, etc. The applications making use of these databases can create and manipulate databases from within their application itself, without requiring any additional software to be installed. These databases support SQL types command. There advantage is that they are easy to setup and require very little maintenance.

c) In-memory: These are the fastest of the breed. The database engine becomes part of the application accessing the database. Few common in-memory databases are Berkley DB, Microsoft's ESENT, Perst, etc. In order to make the data access faster, these databases do not provide support for SQL type command. In any other database type, the support of SQL forces additional layer of parsing to perform data access, and hence make them slower as compared with in-memory datavase. In fact, applications are required to use special APIs to access and manipulate data.

The in-memory databases are hardest to implement, although they have the best performance. However, there are wrappers available to ease out the development process, but still they do require additional work on the developer's end.

Delicious vs. Blogger

I am an avid Delicious user. I bookmark a lot of content on Delicious. Half of my content are technical stuff (software, technology, etc.), and the other half are business news (trends, strategy, analysis, etc.). The business bookmarks are primarily from WSJ.

The other day, as usual I was half way through an article on WSJ; and was getting ready to bookmark that on Delicious. My wife popped up from behind and asked if I ever read the articles bookmarked on Delicious. That made me ponder, I hate to say, as usual she was right this time as well. I hardly go back and read them, although I do refer to technical articles from time to time, but not on the business ones.

From now on, I am planning to add the business articles in my blog as opposed to just stuffing them on delicious. While delicious is painless to use, blog requires some effort to come up with the right choice of words. Will see how it goes.

Bypassing Enterprise Security Through Firefox Extensions

Firefox is gaining momentum in terms of its install base. Most corporates are installing this browser on their typical desktop image. In a typical enterprise environment, a user's desktop is quite locked down. The person cannot install any software as such; has pre defined set of mapped drives, remote backup software, anti virus, and any other enterprise application, all pre installed.

However, there is one catch. Firefox allows extensions to be downloaded and installed without requiring any special permissions. In theory, an enterprise user can download his/her favorite extension on Firefox and do all the things that typically is not allowed to do. This is very similar to the availability of applications on browser such as Google chat, Meebo, Yahoo chat, etc. without requiring any software to be installed locally.

For the enterprise security group it's always a race against new technology, what to block what not to block, and more than often they are too late in figuring that out :)

ISV: Targeted software selling in enterprise

By no mean I am an expert in selling software. However, based on what I know so far, I can tell selling software to an enterprise needs careful planning and above all a good strategy.

A large enterprise has many departments, which mostly function independent of each other, having their own budget, resources, projects, SLA, etc.; a good analogy can be the small boutique shops in a strip mall.

In my experience, there is usually very little inter-department coordination as far as creating a unified solution is concerned. ISVs need to know exactly how many departments are going to be impacted by their software, and try to keep them on board from the get-go.

Departments usually prefer full ownership on software, as opposed to working with other units. Take for instance if your software primarily runs on server, with a bit of desktop component as well. The server group will love to work with you as you are solving their problem. On the contrary, the desktop group will not welcome your solution as it adds burden on them without any perceived advantage.

My advise would be to keep the deployment environment in mind from the very beginning and target your software for 'a' department as opposed to the entire enterprise, unless it's a true enterprise software like SAP and the likes.

Happy selling!