Here’s what Entity Framework (EF) has to offer:

• Using EF with the Model First approach, you design a schema of the model you want to implement, and EF generates a database and the code to implement it. Now, that’s what I call saving time! Using this approach, you can get going really really quick.
• If you already have the code for your model, then EF can generate the database to store this model as well as the rest of the code handling persistance to this database, using the Code First approach.
• In case you already have the database, EF can generate the code using the Database First approach.
• EF uses Plain .Net objects (POCOs) with navigational properties to implement your model. Very easy stuff. The way EF lets you interact with the data once it’s retrieved from the DB is piece of cake (not the fact of data retrieval itself, that can get tricky).
• Automatic code generation with T4 templates. Once you have EF set up in your project, there’s a bunch of templates to generate a lot of code for you. That doesn’t mean you must use it, but it’s there for your convenience, in case you think some templates can help you. Me myself I use some of the T4 templates, but not all of them. There’s some things I actually prefer doing manually.
• Self-tracking entities will greatly simplify the process of implementing an over-the-wire scenario, in which you have different layers spanning across different systems and you have to serialize and de-serialize your entities. EF makes this really easy.
• Local caching, to speed up your data access.
• Lazy loading, which can improve overall application performance.
• Support for LINQ (both coming from Microsoft, you would expect this, right?).
• Convention over configuration. The hottest trend in software development. You wouldn’t think EF would miss it, would you? When starting up a new project with EF, the only thing you need to configure are the database server and its name. Nothing else. All other things are taken care of for you. Of course, if you want more control over what EF is doing, you can tweak it to meet your criteria. But that isn’t something you have do right at the beginning. This way, you can be productive much faster.
• Support for the major databases: MS SQL Server (of course), Oracle, MySQL, PostgreSQL, etc…

And last but not least:

• Coming from a big player in the industry like Microsoft, Entity Framework has great resources and a great community behind it. If you ever have a problem with EF, or want to tweak its behavior, chances are you’ll be finding what you need really fast. If you’re a seasoned developer, you’ll find this is one of the most important features of EF.

If you haven’t tried it out yet, don’t wait any longer and see for yourself what I’m talking about!

If we’re using objects in our application and we want to save them, we’ll probably use some data base system. We’ll most likely establish a connection to the data base, create a SQL sentence with the values of the object (or call some kind of stored procedure), and save them to some table. Easy enough, right? Well, this may seem trivial for a small object with 4 or 5 properties. Just consider an object not so small, with 40 or 50 properties. But… what happens with associations? And… what if the object itself contains some other objects? We’ll store them in the data base as well? All of them or just some? What will we do with foreign keys? We can see that, as the application gets more complex, this translation is not so trivial anymore… As a matter of fact, storing objects in the database can become a very usual source of headaches. There are some studies which state that up to 35% of code is dedicated to the role of translating data between the application and the data warehouse.

And this is where Object-Relational Mapping tools come into play. ORM tools applied to databases transform a DB register to a code object and vice-versa, allowing us to abstract away from writing code to directly access the database. This will speed up development and will allow us to follow the mantra of focusing on business functionalities, not on application plumbing.

But, what exactly can an ORM tool helps us with? Well, they usually do some things like:

• Handle object persistance (to a database, for example). You won’t have to write code for this. And remember, less code means less bugs and less headaches.
• Access different databases. Most of these tools support communicating with different database providers (Oracle, MS SQL Server, MySql, Postgre, etc.).
• Cache. Many of these tools offer some way of caching objects in memory, resulting in much faster data access.
• Help with design. Some of these tools also provide some kind of wizard or graphical interface to aid in the design of the schema and/or database, which leads us to the following point:
• Create your database for you. If you have your data schema already modeled, some of these tools will not only handle how to get the data or how to write it. They can also create the database.

You’re already convinced to use an ORM for your project, right? Good. Now take a look at the most popular ORM tools available for .NET:

• Linq to SQL: not really a full-blown ORM, but it does help with data access.
• NHibernate: I would say NHibernate is one of the most mature ORM projects in .NET, and one of the most used as well.
• Entity Framework: Microsoft’s new kid on the block. Its first version didn’t receive very positive comments, but its latest release looks very good indeed.
• LLBLGen Pro: very mature project, although it’s not the simplest of all.
• DataObjects.Net: quite new, but very promising. It already has a lot of interesting features. Definetely worth taking a look at.

In the next post I’ll be covering Entity Framework a bit. Stay tuned!

So, what if I want to develop my own personal project and I require a RDBMS (Relational DataBase Management System)? Oracle and MS-SQL are out of the question because of their high cost. MS-SQL Express has great limitations, so, although it is free, we won’t be considering it for our purpose. Which is the best open source RDBMS?

Today’s most known open source RDBMS are MySQL and PostgreSQL. PostgreSQL is considered to beat MySQL in the features war. This used to be true some time ago, but it’s no longer the case anymore. 99% of the needs you will have with your RDBMS will be covered by both MySQL and PostgreSQL. Still, there’s many people who think that MySQL has improved a lot, but it’s just not PostgreSQL.

If you want to compare performance, fans of both systems will tell you their RDBMS is faster than the other one. On one hand, PostgreSQL has been recently paying attention to speed, and has been making its product faster and faster with every release. On the other hand, MySQL proponents say that, if configured properly, MySQL’s MyISAM tables are indeed lightweight and make for a faster database.

But probably, the most important thing to consider when choosing which RDBMS you should use, is which one is easier to use. I can tell you that previous Oracle experience will make you feel at home and comfortable with PostgreSQL. Still, the MySQL community seems to be much bigger than PostgreSQL’s, so, should you require some assistance when developing your project, if you’re using MySQL chances are that you will get quick help from them.

MySQL is licensed under the GNU GPL, but offers an alternative commercial license for those who don’t want to be restricted by that license. PostgreSQL uses the BSD license, which stipulates that the credits have to be maintained, but beyond that you can do whatever you want with it.

But, after all, it just all comes down to personal tastes. Just choose whatever you like and whichever you think might fit your needs better. What might be the best for one person, might be a bad choice for another.

Check these links for more info:

• Open Source Database Feature Comparison Matrix
• Comparison of RDBMS

Related posts:

1. Sluggish database view? Materialize it!
2. Entity Framework
3. Persistance layer: object-relational mapping tools

Regular views store just the SQL script needed to retrieve the data, and every time they are consulted the stored SQL query is executed. However, materialized views not only store the script, but the retrieved records as well, making it much faster.

As with regular views, the SQL script defines which data is to be retrieved. However, with materialized views this script is executed when the view is first created, and the result is physically stored in a real table. From then on, when the materialized view is accessed, the DBMS transforms the SQL sentence targeting this table instead of the more expensive procedure of actually querying all elements involved in the SQL sentence.This table can be defined with the same storage parameters used for regular tables (tablespace, etc.). Indexes can be used for materialized views as well, improving the performance even more.

Obviously, the greater the number of tables used, the more benefits we’ll get by using a materialized view. In our project, we were accessing 15 tables: we cut the execution time from 4 seconds to 100 ms by implementing a materialized view… this means that execution was 40 times faster!!! Now, that’s what I call optimization!

However, when designing a materialized view you need to keep in mind that it’s actually going to become a table with static data… and you need to specify when and how that data is going to be updated. Not taking this into account might lead the application to display outdated or incorrect data. This means that we need to evaluate the benefits and drawbacks we’ll get by using a materialized view: it might as well turn out that it slows down the whole system. So I encourage you to do some design and testing before actually deploying the view into production environment.

How to build a Materialized view in Oracle

This is the command used to create materialized views:

CREATE MATERIALIZED VIEW materialized_view_name
 [TABLESPACE ts_name]
 [PARALELL (DEGREE n)]
 [BUILD {INMEDIATE|DEFERRED}]
 [REFRESH {FAST|COMPLETE|FORCE|NEVER|ON COMMIT}]
 [{ENABLE|DISABLE} QUERY REWRITE]
AS SELECT ... FROM ... WHERE ...

The Build parameter

If you choose the BUILD INMEDIATE option, the table associated with the materialized view will be populated with data at creation time. On the contrary, if you’d rather have the table populated in the moment when the first access to the view is performed, then use the BUILD DEFERRED option.

The Refresh parameter

This option indicates the mechanism Oracle will use to update the table representing the materialized view. There quite a few options here, and I would say it’s one of the most important considerations when building a materialized view. I will write a new article explaining the different updating approaches we can use to implement these views.

The Query Rewrite parameter

The ENABLE/DISABLE QUERY REWRITE option indicates whether the Oracle optimizer is allowed to rewrite SQL sentences in a way in which the materialized view will be used in the execution phase instead of the base tables included in the original SQL sentence. This is a rather complex subject, and I will dedicate a post dealing with it.

Other DBMS

This article focused on Oracle’s Materialized Views. But most DBMS implement some kind of view optimization these days. In case you’re using some other DBMS, you might be interested in searching for:

• Microsoft SQL Server: Indexed views.
• DB2: Materialized query table.
• Some other DBMS (for example MySQL and PostgreSQL) don’t have such a feature, but you can implement your own manually using triggers.

Further reading

• Oracle Materialized View Concepts and Architecture
• Microsoft SQL Server 2005 Indexed views
• DB2 Materialized query table

Related posts:

1. Which database to use for a personal project?
2. Persistance layer: object-relational mapping tools
3. Entity Framework