Cagey said:
Ok. We're probably coming from different angles. I'm used to assembly and C, and you're talking about higher-level languages where a great deal of detail is taken care of for you. But, the same principles apply. You have to plan for the future or you risk some serious re-factoring down the road. So, when you create a structure or record or whatever your system calls it, you add in variables you aren't going to use so you can simply rename them later if you need to store some data you didn't think of during the design phase.
For instance, something as simple as mailing addresses can require additional fields because of variations in how countries handle things, but you may not know what those fields are. So, you create a street number, street name, [name2], [name3], city [city2], State [county], etc. where the names I've bracketed are simply fields you don't plan on using, but the structure is there in case you do. That way, file space is allocated and if you do end up using those fields, you don't have to rebuild your database to start using them.
If you do start using them, you'll have some records with those spaces blank. But, you can always fill them in later. But, if the space isn't there to start with, you're screwed. You have to rewrite the code and rebuild the database, which can be a nightmare in some applications.
I see what you mean. I actually started in assembler and C when I first started coding properly about 20 years ago. But by the time I left school, it was already incredibly rare to see assembly being written, and C was on its way out too.
Now that our machines are so
insanely powerful compared to those we had back then, we never, ever need to worry about these problems. Or we sometimes do, but only when we're doing something incredibly specialised. For instance at my last job the platform I was working on was written in C#, but I spent a few weeks making a new memory manager for a particularly performance-intensive area of the code because the built-in .NET one was causing delays. These were sub-millisecond delays but the performance impact was unacceptable in that context.
However, on a guitar design web site, forget it. Need to add a column months into the project when it's already gone live? Just add it. The RDBMS will take care of everything. If I was creating a structure in the code to represent a piece of data in the database, I wouldn't add spare fields to save that space, because when I was committing the structure to the database I wouldn't be doing it as a single binary chunk of data. I'd be taking the fields of that structure and storing them in separate columns in the db table. So, when I need a new field, I'd add it to the structure, add the column to the database table, and then add the handling to the saving and loading code. And in fact, increasingly, I wouldn't even have to do that, because I'd be using an ORM framework that took care of it for me. I tell it there's a new field, and both the application code and the database are magically updated. And I just start using the new field.
Of course, you might think this make things too easy. But it doesn't, it just means that boring stuff doesn't take up our time, and now we spend that time doing much harder stuff. Well, not objectively harder to code, but harder to get your head round. International database replication, horizontal scaleability and mult thread/process/centre architecture. To be quite honest, these types of problems
massively less interesting. I would
much rather be adding reserved columns in a struct and passing it around in pure binary format. That's real coding. What I do these days is gluing together code that vendors already wrote. Boring, but you don't half get shite done.
ANYWAY...
I like geetars.
