Databases and Automation vs. Hand editing - Design Block
Posted: Mon Mar 21, 2005 9:03 pm
I've hit a design block, primarily because of the way I percieve the data that's being handled. For instance, with a forum, you're working towards having it totally automated: you're not going to have people hand editing the database for posts. Yet I don't feel I want my application to be that way... which brings up my first fundamental question:
Should all web applications work towards being fully automated, and then build in a moderation system? Or should one try to get something running as soon as possible, making moderation the only choice, and then slowly change the parts as you move towards automation? The first choice won't get anything done in a while, but it's the much more direct path. The second way will ultimately result in more code being written and more steps in the wrong direction.
See, if I work towards that, it breaks one of the nice things about my site, which is intimacy through unpopularity. And fully automating things is going to be a monumental task for me to do... which is why I'm reluctant to take the try to target that first (I've got other things in the code I want to work on). So I'm trying to connect with what I have right now.
What do I have right now? A propriety data storage form: It works sorta like PHP's variable/array constructors, but that's all it can do (and that's all it's supposed to do). I've written code to parse it, and the code is kinda slow (it's okay if you call it only once, but many times and...) Plus the structure is ugly: you always seem to be missing things.
So, what I thought I would do was first clean up the data. Objects sounded like the way to go: they would let me blueprint and hold lots of data while letting me implement methods for easily hooking into the old interface. I finished the author class.
Of course, the author class was the easiest of them all: it didn't have anything too tricky, just a few values for the author. It would be the stories that would be difficult: there was complicated logic in determining the organization of a chapter story, logic I'm not quite sure I want to keep (although it may not be too bad after all...)
But then, looking at the code, I came up with a problem. Right now, this is how my data is managed:
When I found out about serialize, I intended to do this:
But that meant I would have to write complicated subroutines when I meant to edit the object and it's associated code.
I had no idea why people had databases in the first place: why not just provide mechanisms for "storing" data structures, rather than make lots of queries to populate your structures?
What is the fundamental use for Databases: what makes them so good?
I'm beginning to suspect is that while data inside a data structure is hard to manipulate, the database itself is easy to edit.
Well, at least, easy for a program to edit.
Which comes back to the problem of automation: I have to extend my programming to have complete editing subroutines if I want the program to be able to do all the editing by itself. And that's going to take a lot of time.
When you want to move databases, you have to do "database dumps", which are essentially large files of lots of instructions on how to recreate a database. That's a nightmare for someone who just wants to make simple changes to something.
Ughh.... I can't think anymore. Can anyone answer the first two questions and I'll reveal more about my dilemma as I think some more... I think the main problem is I'm not thinking... I need to do some research too... and maybe I should just bite the bullet and go for the conceptually correct way.
Should all web applications work towards being fully automated, and then build in a moderation system? Or should one try to get something running as soon as possible, making moderation the only choice, and then slowly change the parts as you move towards automation? The first choice won't get anything done in a while, but it's the much more direct path. The second way will ultimately result in more code being written and more steps in the wrong direction.
See, if I work towards that, it breaks one of the nice things about my site, which is intimacy through unpopularity. And fully automating things is going to be a monumental task for me to do... which is why I'm reluctant to take the try to target that first (I've got other things in the code I want to work on). So I'm trying to connect with what I have right now.
What do I have right now? A propriety data storage form: It works sorta like PHP's variable/array constructors, but that's all it can do (and that's all it's supposed to do). I've written code to parse it, and the code is kinda slow (it's okay if you call it only once, but many times and...) Plus the structure is ugly: you always seem to be missing things.
So, what I thought I would do was first clean up the data. Objects sounded like the way to go: they would let me blueprint and hold lots of data while letting me implement methods for easily hooking into the old interface. I finished the author class.
Of course, the author class was the easiest of them all: it didn't have anything too tricky, just a few values for the author. It would be the stories that would be difficult: there was complicated logic in determining the organization of a chapter story, logic I'm not quite sure I want to keep (although it may not be too bad after all...)
But then, looking at the code, I came up with a problem. Right now, this is how my data is managed:
Code: Select all
DATABASE ---PHP parser (slow)---> PROGRAM (in abstract form) ----> SERVEDCode: Select all
OLD DATABASE ---parse---> PROGRAM (in abstract form) -----\/----> SERVED
---serialize----> SERIALIZED DATA (physical manifestation of abstraction) ---------> back to PROGRAMI had no idea why people had databases in the first place: why not just provide mechanisms for "storing" data structures, rather than make lots of queries to populate your structures?
What is the fundamental use for Databases: what makes them so good?
I'm beginning to suspect is that while data inside a data structure is hard to manipulate, the database itself is easy to edit.
Well, at least, easy for a program to edit.
Which comes back to the problem of automation: I have to extend my programming to have complete editing subroutines if I want the program to be able to do all the editing by itself. And that's going to take a lot of time.
When you want to move databases, you have to do "database dumps", which are essentially large files of lots of instructions on how to recreate a database. That's a nightmare for someone who just wants to make simple changes to something.
Ughh.... I can't think anymore. Can anyone answer the first two questions and I'll reveal more about my dilemma as I think some more... I think the main problem is I'm not thinking... I need to do some research too... and maybe I should just bite the bullet and go for the conceptually correct way.