Know your database
You'll have to know your database in the end. Here are the great benefits of an ORM:
- Helps seperate your business logic from your storage mechanism
- It's easy to program "naturally" in the languages object mechanism
- Get high productivity at the beginning of the project and during maintainance
- Get the benefits of a scalable, language nuteral, storage engine compared to rolling your own object file dumps
- You write much less code
- Less likely to accidently create a SQL injection vunerability
However some, nameless, people are starting to adopt the idea that an ORM means you don't have to (in their words) "Worry about the database". You don't want to concern yourself in its effeciency or optimisation.I must say I really disagree with this. I went to University and got shown the benefits of data structures and algorithms. Why to use an array over a linked list or vice versa. How to organise your data into a tree and search it effeciently. How sorted data can make slow code fast. Why it is important to get the foundations of your programs correct to build scalable solutions upon them.
ArrayLists are pretty nice when you're say validating a user's choice from a drop down. If you're dealing with less than 40 or so items in your data structure you can use pretty much any container you want. I wouldn't argue that. However when you're core system is managing thousands bookings or bets or patient details or something, you really aught to invest in choosing the right data structure to model your data. Maybe not today and maybe not tomorrow. Avoid premature optimisations if you can. Sooner or later you're going to need to speed that code up and when the time comes, you'll need knowledge of data structures and algorithms to do it.
Sooner or later you're going to need to speed that database up too, so you're going to need that knowledge of databases, SQL, indexes, joins, query plans and other database complexities too. Your database is the heart of your system. Most non-trivial solutions use them as a communications platform as well. Don't pretend understanding your database is not important because it will be. Use ORMs, use their configurations to specify primary keys, joins, indexes and unique fields and so on, but understand those are database concepts.
What exactly do I need to know?
It would be basically bad blogging to assert you should know more about something and then not continue and actually explain what that something else is. It boils down to these:
- How do design a normalised database with logical relationships between tables and minimal duplication of data
- What a database constraint is
- What an index is and how it improves effeciency
- How to analyse the effeciency of a SQL statement and improve it
So expect follow up posts from me soon outlining these things!