September 21, 2010 at 10:54 am
Steve Jones - Editor (9/21/2010)
... We discarded MySQL and PostgreSQL for this site early on, even when funds were tight, because we weren't familiar with them and they were still young in 2001. I think that's a valid choice.
For this site? Had word got out that SQLServerCentral.com was powered by MySQL, then Sun Micro would have had a field day.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 21, 2010 at 11:00 am
mtillman-921105 (9/21/2010)
To what extent were relational DBMS created because drive space wasn't cheap and processing power was weak? Big, flat tables weren't helpful in either case years ago.Now I've staked my career on SQL Server, so don't just jump all over me. But I've seen this point brought up elsewhere and wondered how bad it would be to just use flat tables. All the other software may not be dead, but it is bloated! Why not databases too? Summary tables could be created on the side too, which of course helps performance.
Video graphics cards work in a brute force, but kind of a dumb way. But they do work - right?
Someone respectfully prove me wrong. Please. (Because frankly, I'm a little worried.) :w00t:
I've still got a shrink wrapped copy of FoxPro 2.6 for DOS, if you're willing to trade for a SQL Server 2008 Enterprise license.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 21, 2010 at 11:33 am
Eric Russell 13013 (9/21/2010)
mtillman-921105 (9/21/2010)
To what extent were relational DBMS created because drive space wasn't cheap and processing power was weak? Big, flat tables weren't helpful in either case years ago.Now I've staked my career on SQL Server, so don't just jump all over me. But I've seen this point brought up elsewhere and wondered how bad it would be to just use flat tables. All the other software may not be dead, but it is bloated! Why not databases too? Summary tables could be created on the side too, which of course helps performance.
Video graphics cards work in a brute force, but kind of a dumb way. But they do work - right?
Someone respectfully prove me wrong. Please. (Because frankly, I'm a little worried.) :w00t:
I've still got a shrink wrapped copy of FoxPro 2.6 for DOS, if you're willing to trade for a SQL Server 2008 Enterprise license.
That is funny, but FoxPro was relational believe it or not. (I was a FoxPro programmer and have actually worked with that version.) In fact, I think that even dBase III+ was relational, for that matter.
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking
September 21, 2010 at 11:36 am
We did worry about the rep of this site using MySQL, and used that to negotiate a better license from MS at one point. 😛
September 21, 2010 at 11:58 am
NOSql is an interesting platform.
I personally hope that one day, somehow, nosql would be usable in the common rdbms platforms. That could be interesting.
September 21, 2010 at 12:37 pm
When I stop and think about it, this all so really sad... The thought all of my precious, lonely tables never again being able to have relations... you know - I don't know that I can bare it...
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking
September 21, 2010 at 12:55 pm
mtillman-921105 (9/21/2010)
Eric Russell 13013 (9/21/2010)
mtillman-921105 (9/21/2010)
To what extent were relational DBMS created because drive space wasn't cheap and processing power was weak? Big, flat tables weren't helpful in either case years ago.Now I've staked my career on SQL Server, so don't just jump all over me. But I've seen this point brought up elsewhere and wondered how bad it would be to just use flat tables. All the other software may not be dead, but it is bloated! Why not databases too? Summary tables could be created on the side too, which of course helps performance.
Video graphics cards work in a brute force, but kind of a dumb way. But they do work - right?
Someone respectfully prove me wrong. Please. (Because frankly, I'm a little worried.) :w00t:
I've still got a shrink wrapped copy of FoxPro 2.6 for DOS, if you're willing to trade for a SQL Server 2008 Enterprise license.
That is funny, but FoxPro was relational believe it or not. (I was a FoxPro programmer and have actually worked with that version.) In fact, I think that even dBase III+ was relational, for that matter.
I think the last line of code I wrote in FoxPro was back in '98. A FoxPro table was basically a flat text file with a header record on the front containing column names and the offset of the last record. I know there are still people out there using FoxPro or some variant, because over the years I occasionally have to import from it into SQL Server.
As for FoxPro 2.6 being relational, we would create a cursor by opening a table and then joining it with other tables using a primeval version of SQL, and then loop between each record. Many FP developers would simply put all their columns in the same table and called it a 'database'. Indexes were stored in seperate files. When opening a table, we had to explicitly opening it's related indexes too, and if we didn't, then any records we inserted or updated would simply not be updated in the index. You knew when the indexes were not updated correctly whenever users called in the middle of the night to complain about missing data. There was no client / server engine, the tables were put out on a network file share, and every page read had to be pulled across the wire to the user's local PC. If a user shut down their PC with the application open (or if the application crashed), then whatever tables or indexes were open at the time would get corrupted and couldn't be opened without re-indexing or sometimes manually editing the table header with a HEX editor. :w00t:
Processing, spooling and caching were all pulled across the wire to the user's PC, so it made more efficient use of (the server's) disk storage space. I recall that sometimes whenever a user was running a really large report, the spool tmp file would fill their local HD and crash the PC. I'll gladly shell out $1,000 of my own money for a couple more hard disks just to avoid retrograding back to ISAM databases and applications.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 21, 2010 at 1:14 pm
Eric Russell 13013 (9/21/2010)
mtillman-921105 (9/21/2010)
Eric Russell 13013 (9/21/2010)
mtillman-921105 (9/21/2010)
To what extent were relational DBMS created because drive space wasn't cheap and processing power was weak? Big, flat tables weren't helpful in either case years ago.Now I've staked my career on SQL Server, so don't just jump all over me. But I've seen this point brought up elsewhere and wondered how bad it would be to just use flat tables. All the other software may not be dead, but it is bloated! Why not databases too? Summary tables could be created on the side too, which of course helps performance.
Video graphics cards work in a brute force, but kind of a dumb way. But they do work - right?
Someone respectfully prove me wrong. Please. (Because frankly, I'm a little worried.) :w00t:
I've still got a shrink wrapped copy of FoxPro 2.6 for DOS, if you're willing to trade for a SQL Server 2008 Enterprise license.
That is funny, but FoxPro was relational believe it or not. (I was a FoxPro programmer and have actually worked with that version.) In fact, I think that even dBase III+ was relational, for that matter.
I think the last line of code I wrote in FoxPro was back in '98. A FoxPro table was basically a flat text file with a header record on the front containing column names and the offset of the last record. I know there are still people out there using FoxPro or some variant, because over the years I occasionally have to import from it into SQL Server.
As for FoxPro 2.6 being relational, we would create a cursor by opening a table and then joining it with other tables using a primeval version of SQL, and then loop between each record. Many FP developers would simply put all their columns in the same table and called it a 'database'. Indexes were stored in seperate files. When opening a table, we had to explicitly opening it's related indexes too, and if we didn't, then any records we inserted or updated would simply not be updated in the index. You knew when the indexes were not updated correctly whenever users called in the middle of the night to complain about missing data. There was no client / server engine, the tables were put out on a network file share, and every page read had to be pulled across the wire to the user's local PC. If a user shut down their PC with the application open (or if the application crashed), then whatever tables or indexes were open at the time would get corrupted and couldn't be opened without re-indexing or sometimes manually editing the table header with a HEX editor. :w00t:
Processing, spooling and caching were all pulled across the wire to the user's PC, so it made more efficient use of (the server's) disk storage space. I recall that sometimes whenever a user was running a really large report, the spool tmp file would fill their local HD and crash the PC. I'll gladly shell out $1,000 of my own money for a couple more hard disks just to avoid retrograding back to ISAM databases and applications.
Yeah Eric, I wish I could say that the last line of FoxPro code I wrote was in '98. I waited too long to switch over, but I was stuck there for a while. By the way, FoxPro has a bad rep, but for a lot of applications that are running today - FoxPro would do just fine if MS wouldn't cap it off at 2GB per table. The newer versions are a lot more advanced than a lot of people think. I shake my head every time I see some minor 4 GB database running on SQL Server (or worse, Oracle) since it's like swatting a fly with a nuclear bomb. I have to hand it to MS's marketing for convincing everybody that it's "SQL Server or nothing" basically. (Or "If you must, then use Access.")
Anyway, yes, back then the state of the desktop database tech was not impressive by today's standards. But still, you didn't have to resort to using single, stand-alone flat tables - you could normalize the data (and make it "relational").
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking
September 21, 2010 at 1:33 pm
mtillman-921105 (9/21/2010)
Yeah Eric, I wish I could say that the last line of FoxPro code I wrote was in '98. I waited too long to switch over, but I was stuck there for a while. By the way, FoxPro has a bad rep, but for a lot of applications that are running today - FoxPro would do just fine if MS wouldn't cap it off at 2GB per table. The newer versions are a lot more advanced than a lot of people think. I shake my head every time I see some minor 4 GB database running on SQL Server (or worse, Oracle) since it's like swatting a fly with a nuclear bomb. I have to hand it to MS's marketing for convincing everybody that it's "SQL Server or nothing" basically. (Or "If you must, then use Access.")Anyway, yes, back then the state of the desktop database tech was not impressive by today's standards. But still, you didn't have to resort to using single, stand-alone flat tables - you could normalize the data (and make it "relational").
You're right, VFP 3.0, which was released in '95, made some improvements. There was this database container thing that would group related table and enforce referential integrity. Also, the newer .CDX indexes were linked to the .DBF files and would automatically open when the table was opened. The language and IDE was far more advanced, but still it was not client server, just a collection of files sitting on a file server, and the files would go bad on your from time to time.
Now the IDE for VFP 3.0 was way ahead of Visual Basic 3.0; it supported object classes, OOP, compiling GUI controls, etc. Visual Basic didn't support that same level of functionality until VB.NET in 2000.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 21, 2010 at 1:49 pm
You're right, VFP 3.0, which was released in '95, made some improvements. There was this database container thing that would group related table and enforce referential integrity. Also, the newer .CDX indexes were linked to the .DBF files and would automatically open when the table was opened. The language and IDE was far more advanced, but still it was not client server, just a collection of files sitting on a file server, and the files would go bad on your from time to time.
Now the IDE for VFP 3.0 was way ahead of Visual Basic 3.0; it supported object classes, OOP, compiling GUI controls, etc. Visual Basic didn't support that same level of functionality until VB.NET in 2000.
Well, we knew that VFP was a dead-end road once it was skipped over when .NET came ou... Hey, wait a minute! When's MS going to include .NET stuff in SQL Server? :angry:
(And no, CLR doesn't count, either.)
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking
September 21, 2010 at 1:59 pm
mtillman-921105 (9/21/2010)
Well, we knew that VFP was a dead-end road once it was skipped over when .NET came ou... Hey, wait a minute! When's MS going to include .NET stuff in SQL Server? :angry:(And no, CLR doesn't count, either.)
Give me an example of what .NET stuff you would like so see [in] SQL Server.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
September 21, 2010 at 2:15 pm
Eric Russell 13013 (9/21/2010)
mtillman-921105 (9/21/2010)
Well, we knew that VFP was a dead-end road once it was skipped over when .NET came ou... Hey, wait a minute! When's MS going to include .NET stuff in SQL Server? :angry:(And no, CLR doesn't count, either.)
Give me an example of what .NET stuff you would like so see [in] SQL Server.
Actually, I was just joking. 😀
Steve, my apologies for hijacking the thread here - we seem to have gotten a little off topic.
The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge. - Stephen Hawking
September 21, 2010 at 3:26 pm
I'm not sure is a solution such as Ab Initio counts as NoSQL but if so its industrial strength in a way that would make I.K.Brunel's work look a bit flimsy.
September 22, 2010 at 3:11 pm
Just like Steve noted, it is a tool. ACID databases were targeted for financial transaction systems, where ACID was a must, and hard, known relations existed. And the ACID recovery model adds overhead.
Vertica, Greenplum and the Hadoop/BigTable/MapReduce/Cassandra tools add great value to loose data where relations are not known ahead of time.
Its all about using the right tool.
The more you are prepared, the less you need it.
December 15, 2010 at 4:47 pm
We are now sponsoring an open source JBDC driver for Amazon's SimpleDB called SimpleJDBC.
For more information:
http://www.jnetdirect.com/index.php/products/simplejdbc.html
Viewing 15 posts - 16 through 29 (of 29 total)
You must be logged in to reply to this topic. Login to reply