Are we going back to frame-style usage?

Post #273,995 by drewk 11/26/06 10:38:22 PM Reply	Are we going back to frame-style usage? What you're talking about sounds like the way I understand mainframe "databases" work. I may be making connections that aren't there, but it sounds like there was a style that worked well on the frame. Then we developed relational databases. They were a convenient abstraction for the programmers. They worked well for smaller problems and smaller datasets, and ran on midranges and workstations. Then as the available horsepower grew some of the old frame jobs were re-written to use relational DBs on fast workstations. (Yes, Barry, this means you.) Now it sounds like the problems we're trying to solve -- the size of data and the number of transactions -- are exceeding what we can do well with relational DBs. So now people are starting to re-invent the style of creating their own domain-specific database. Is this completely wrong? === Kip Hawley is still an idiot. === Purveyor of Doc Hope's [link\|http://DocHope.com\|fresh-baked dog biscuits and pet treats]. [link\|http://DocHope.com\|http://DocHope.com]
Post #274,010 by static 11/26/06 11:49:21 PM Reply	Interesting take on things. Has some merit, I'll admit. I thought I liked the idea of having one MySQL database tuned for some of my data and another tuned differently for another lot of data. You're suggesting that flatfiles might be better for some other types of data and perhaps some other, highly custom arrangement better for another sub-domain. But then, you couldn't do the sort of adhoc stuff on mainframe datasets that we do now on many relational DBs. You had to program something and wait for it to finish. Which might be several minutes, it might be several hours, it might be several days. I think the role of 'database programmer' is being re-invented. Wade. "Don't give up!"
Post #274,017 by crazy 11/26/06 11:55:34 PM Reply	Best tool for the job and all that People treat SQL databases as golden bullets for their data storage needs, rarely taking into account the downsides. Time to take a step back and figure out what you really need to accomplish, and THEN determine the best method of storage and access.
Post #274,032 by tuberculosis 11/27/06 1:28:49 AM Reply	Yah Too many people just think "I need to store a lot of data on disk - I guess I need a database". They don't realize that databases COST you something too. If its just about persistence - probably you can do better with plain old files. OTOH, if you really do have a lot of different ways of looking at your data, then a database is just the thing. I'm actually moving an app from an oodb, which is mostly only good at persistence, to postgres because I have ever expanding reporting requirements. [link\|http://www.blackbagops.net\|Black Bag Operations Log] [link\|http://www.objectiveclips.com\|Artificial Intelligence] [link\|http://www.badpage.info/seaside/html\|Scrutinizer]
Post #274,120 by drewk 11/27/06 8:07:37 PM Reply	Power of abstractions vs. absolute performance OODBMSs are supposed to offer better abstractions to make programming easier, but I haven't heard anyone say the performance is acceptable. Eventually the hardware will pick up enough that today's experiments will become practical. But by then we'll be trying to do more, with more data. Maybe we should keep the greybeards around so that when we hit the wall of what we can do with current hardware, they can remind us how they used to do things. === Kip Hawley is still an idiot. === Purveyor of Doc Hope's [link\|http://DocHope.com\|fresh-baked dog biscuits and pet treats]. [link\|http://DocHope.com\|http://DocHope.com]

Welcome to IWETHEY!