Comment by beachy | Hacker News Reader

Comment by beachy | Hacker News Reader

Plenty of good suggestions in here about e.g. tests, source control etc. You will need them all.

But I would start by choosing how and whether to fix up the crown jewels, the database.

You say that instead of adding columns, team has been adding new tables instead. With such behaviours, it's possible your database is such a steaming pile of crap that you'll be unable to move at any pace at all until you fix the database. Certainly if management want e.g. reporting tools added, you'd be much better to fix the database first. On the other hand, if the new functionality doesn't require significant database interaction (maybe you're just tarting up the front end and adding some eye candy) then maybe you can leave it be. Unlikely I would imagine.

Do not however just leave the database as a steaming pile of crap, and at the same time start writing a whole lot of new code against it. Every shitty database design decision made over the previous years will echo down and make it's ugly way into your new nice code. You will be better for the long run to normalise and rationalise the DB first.

Good point. Using stored procedures / views etc will help crystalise the API for the DB and allow work to happen behind that wall without breaking anything else in the meantime too. Once the work is done, bits of the wall can be replaced with better bits of wall i.e. improved sp's and views pointing to an improved schema.

Yep. views in RDBMS are much underrated, IMO just because they are old tech. It should be possible to use views to:

1) normalise the database (fold these ugly add-on tables as columns in the parent table, with suitable null constraints, then drop the add-on table).

2) Use views to add the add-on tables (now views) back in again.

3) Continue running the old application code against the views, which present the old, ugly schema.

4) Simultaneously write the new code against the normalised core tables.

This use allow to update SELECT operations, but UPDATE / DELETE still have to be done on the old underlying schema right ?

No way to trigger a DELETE from a view right ? How would you approach this ?

Views can be updatable though there are caveats, but deletes and updats can be done via a function or stored procedure, meaning there's no direct access by the app to the underlying schema. If it's done well it means that the calling code in the app won't have to change (or at least be minimised) even as the schema changes. The speed and security benefits are a nice by-product.

You can even do things like prevent the app from deleting things unless the functions are used and prevent poor development practices in the process.

Reply on news.ycombinator.com