On Fri, 21 Apr 2006 11:08:33 -0500 Rod Engelsman <[EMAIL PROTECTED]> wrote:
> Joe wrote: > > >> > > It probably doesn't matter much today with faster processors and > > more memory, but a change like that would also involve making > > everything bigger - both programs and data files. And, because it > > was bigger, it would involve more disk access and processing time to > > handle. So, aside from the programming difficulties, there would be > > a performance hit for a benefit most users don't need. (I've seen a > > lot of posts here about OOo being or starting up too slow now!) > > > > Not being a big spreadsheet user, I can't imagine having a > > spreadsheet that's anywhere near as big as the current limits. It > > seems that it would be extremely unwieldy and very easy to get lost > > in and make unintentional changes that would be extremely difficult > > to locate and repair. I don't think anybody would need to write a > > spreadsheet program anywhere near that big that wouldn't be better > > split into separate sheets or programs, so the rest must be data > > rows. > > > > As has been said here many times before, if you've got that much > > data, the only effective way to deal with it is through the use of > > external files using things like databases. > > > > If all you have (know) is a hammer, everything looks like a nail > > (spreadsheet). > > > > Joe > > It depends. I had the exact opposite situation a while back. I'm > reasonably proficient with a spreadsheet, but not so much with > databases. > > So I had a situation where I needed to massage some data that I had > procured as text files. Do some statistics and draw some graphs, that > sort of thing. It turned out to be over 62000 data sets. But DataPilot > was the perfect tool to do what I needed. Oh no it wasn't ;) It was the tool you were familiar with. A database is the best tool for this (snuffle - nuthins perfect). > I probably _could_ have worked it out by creating a database, but it > would have taken me a whole lot longer because I would have spent > considerable time just screwing around figuring out how to do it. But the experience gained pays for itself. > Now if it had been 72K instead of 62K rows I would have had no choice. Next time it might be. > You can create dictionary definitions of "spreadsheet" and "database > app" that make them into completely different animals, but in real > life applications there is a considerable overlap. > Not when you get into relational databases - real world stuff. A spreadsheet will handle single table type stuff sort of. It won't do it as well as a database. Think about this example - people and their email addresses. You have a person, you have an email address, simple. But then you have the same person that wants to contact you from work and home. One person - Two email addresses. He tells his wife and she signs up using the same home email address, and her work address. Two people - three email addresses. Their daughter signs up as well at home. Three people - three email addresses. With a flat database (spreadsheet) you have five entries. dad - home dad - dads work mum - home mum - mums work grl - home with a relational database you have two tables with three in each and the crossreference info. dad \|/ dads work mum -|- home grl /|\ mums work Sorts and lookups are then done much faster as there are less to sort through. Sort by person or sort by email. Look up the person then list their emails. Really simple example but just enough to explain my point (i hope). -- Michael Those that can, do; those that can't, teach. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
