Mark’s Site

Some call it coding preparation, others will call it planning and design, but we’re talking about the same thing. The more I code, the more I see professional programmers who just want to code. They don’t care if the design is complete. After all, they have enough info to get started right? They have the [...]

Stuff you need to know about downgrading

When I first started web development, one thing I was always torn on was how to design my screens. I had loads of information that I needed to display in some meaningful, easy to search format. After many years of trial and error, I’ve now got my ‘template’ screens that I use for all my content management screens.

My preferred approach to any moderately sized system is a modular, or component based approach.

So you probably know that for a given SQL user, you can specify what permissions the user can have, such as CREATE, DROP, INSERT, UPDATE, DELETE etc. But are you one of those people that just sets up a general user with S/I/U/D permissions and leaves it at that?

Time to share some serious code I’ve developed my classes with flexibility and ease of use in mind. What follows are actual classes used in my application to handle requests to and from the database.

Do you necessarily assume that ‘delete’ actually means deleting data in your system? Perhaps you should consider simply hiding the data when information is deleted, so in emergencies, data can be recovered without the need for actual database recovery extremes.

When you’re allowing content to be managed by various users, whom you may or may not trust, you need some form of control. That control comes from a well thought out security system.

You’ve got your database diagram at a point where you can see all the relationships among your entities, what now?

So you’ve got your ideas vaguely sorted. How do you proceed from here?