Forum Moderators: coopster
As I have been working through my .csv of this growing set, I'm wondering when to make the jump to MySQL and do a complete overhaul to a relational database. I'm currently looking at about 14 rows of information, with more on the way. We are looking at about 2-3 thousand products, in several styles, each with options (the 14 rows), for many different uses.
I'm getting more and more familiar with PHP and was thinking that it was time to dive into MySQL in order to make things easier for the updates as well as adding new vendors and product lines.
At what point is it worth it to make a jump?
Brett, I believe, has stated that he prefers a flatfile on this forum, but a website that sells products is a different sort of beast.
I've seen the term "roll up your own" quite often when it comes to shopping carts, and I'm willing to put in the time to get what I want. Well, up to a point. (Learning MySQL is one thing, reproducing a clone of OS Commerce is just silly. But, if I do it right...it may be a "pick and shovel" to sell on the side.)
I already have several hundred of my existing products spidered/listed/ranked well/etc.
.htaccess is a good friend and I'm pretty familiar with that also, so that's not a problem.
What I'm finding is that I'm spending more and more time rewriting code (php) to parse the file correctly with all the new variables and staring at me is several new vendors and product lines.
Is there some sort of a threshold one crosses that pushes you toward a database vs. a flatfile?
Yeah - and you've crossed it!
Relational databases allow for more flexibility while sacrificing very little in the way of speed and spiderability - if done right. On the other hand - they offer so much in return!
Yes, the threshold you cross is the need or desire to store data ;) -- hehe
But seriously, your statement:
Brett, I believe, has stated that he prefers a flatfile on this forum, but a website that sells products is a different sort of beast.
may very well be the answer to your question. You were probably referring to this thread [webmasterworld.com...] where Brett states some very good points, particularly where and how your data is going to be stored and accessed. You also need to consider the future. You develop this cart system for a client that has a few products. Later, a new client comes about asking for the same thing. You say, "Hey! I can just use the cart system I wrote for my other client!" Except the new client has thousands of products. Would this impact your decision-making? Sure will.
I guess the bottom line is you need to consider many factors. Personally, I prefer databases for the systems I develop, which are mainly indexed, relational data based systems. I'm with lorax on this one and would use a database.
"I've been sitting here for the past several days trying to work through..."
I've been here, ScottM! Have you ever had to do any flatfile repair work? It sucks. I've had them get corrupted and lost data integrity which takes hours to repair on files of any size.
I have a client that I started out on a flatfile system rather than set them up with a database -- thinking the number of rows would remain small and easily manageable. Yeah, right. They ran with it and it grew into a monster. It has grown well beyond the original project scope laid out years ago. It now lends itself to the requirements of a database and I am not looking forward to the changeover, not unlike the situation you are no doubt experiencing right now. In this particular case, a project went beyond original scope and I'm stuck with the repercussions. I can't tell you how often I wish I had written this using a database. This single event has actually led me to want to use a database whenever I store data now.
Lastly, I'm assuming to update a file you currently read it into memory, update the array or string, and write the entire file back out again, replacing the original file contents entirely. At least, that's fairly common practice with flatfiles, unless you open a stream as binary, etc. Well, with a database, this routine can go bye-bye. Welcome to the UPDATE statement! That alone is worth the move if you ask me.
just think if flatfiles were the true answer why would anyone use db at all. ;)
DB's are faster, less coding and more powerful, point blank.
I have built a bunch of systems on flatfile and there was always some sort of work around that had to be developed and all the while the sql JOIN ORDER BY GROUP BY was echoing in my head.
Now to head off to learn about normalisation....
I just did a decent product mnagement db using a single table. Theres a fair bit of redundancy in the data(Merchants, Countries, Sizes, Colors etc) but the development was much simpler.
I wouldnt just assume a normalised design, you get most the features of a rdbms whatever design you choose.
