Mark’s Site

From Schema to Classes

When you have your database schema created, it’s time to move into coding mode

You can take one of two directions at this point. Classes or no classes. I’ll talk about both here.

The Classes Approach

I always use a very basic object oriented approach where possible and treat database entities as objects, which in turn become my classes. I say ‘basic’ because the world of OO is, imho, overly complex for many a web application and unnecessary, so I keep things simple and use classes purely as a wa of grouping my code, which I find allows for a very organised application

To continue, if, in my schema, I have page, page_category, member, I will create classes mapped to these entities, named Page, Page_Category and Member, and map all the database schema fields as class variables.

Your classes act as your pipeline to your database. If any database entities change, so do your classes. You can now understand the importance of taking your time with the database diagram, and making sure you’ve thought of everything you can, because once you start this step, you really don’t want to be changing your database. If you do you’ll just be creating more work for yourself.

Example: An example class structure for a database entity Page:

Arguments For

This structure, to me, is very easy to understand, whether I’ve been working on an application for years, or am brand new to the development team and want to find my way around. If I’m new, I just have to visit the classes to see how to interact with the database. Nice, simple and organised.

Arguments Against

Some programmers (stubborn fools imho) argue against the object oriented approach of programming and say that using classes is just overhead and takes more time to process. They argue that it offers no more organisation of your code, but I find this very hard to believe as I’ve tried not using classes in projects and I always find my application scales much more easily if I use classes (as it’s far easier to find things!). So my point is, anyone who argues against using classes is an unorganised git who will quickly get in over their head when their applications need to scale

The No Classes Approach

If you choose to take this path, at least be organised and create functions that do the ‘talking’ to the database entities. If you don’t, and you 1) change some database entities, or 2) get more programmers into your project, your application will take longer for new people to learn what’s going on, as your SQL code will be all over the place, and making changes will require first hand knowledge about where all SQL calls in your code are.

So let’s continue assuming you have groups of functions that do all your SQL work This just means you need to name your functions with care, so it’s easy to know what entities you are updating.

Example: I might create a function like so

When coding, I’ll know relatively easily what the name of my function is to run an INSERT statement to the page entity, provided of course that I have documentation in place to point me towards the right function (see, classes would make things easier to find)