Aaaand many that can 'import' from various spreadsheets. That argument may not be meritless, especially if you take in account the old DOS based ASCII flat file databases.

AAAAAAAnd, there's many that will export to CSV files...

Heh, I will say something in defense of that argument. There literally are databases that use flat text files that have a structure not unlike CSV files. Now, whether or not you consider that 'low-rent', I'll leave to you.

Hehehe...

Steven W wrote: ↑

2024-10-21 23:15

Yeah, I'm familiar with the argument that a spreadsheet is technically a database...

! wrote: ↑

2024-11-01 06:22

Well, technically, Excel file is a database.

LOL, as I said I'm familiar with the argument. Not that I personally agree.

Well, technically, Excel file is a database.

I suppose that Interface thing isn't exactly a tiny detail. I once helped create a Excel spreadsheet, using VBA macros, that basically acted like a database UI. It was used for receiving products from various customers. It would save a copy of itself using info I entered on 'sheet1' and you could enter the products by typing in a model number and either a serial number or something very similar. I would sort the customers products by model and I used a barcode scanner to scan the 'serials'. I used VBA to check if the serial met certain criteria, such as length, character-legality, etc. If, everything was okay, it would create an entry on sheet2, then blank the serial 'field' and let me keep going (the barcode scanners can be set up to emulate pressing the Enter key or pressing TAB). When finished with one model, I'd just change the model 'field' and keep going. I used a solid color to fill in the fields you couldn't use on sheet1 and locked the stuff you couldn't change. It would play a wav file (DING.WAV) if the 'serial' was too long, had illegal characters, etc. I suppose, something I might look for in a DB is something that allows you to easily create something similar to what I did with VB in that spreadsheet without the need for all the code. That spreadsheet has since been replaced with a purpose-built UI that directly accesses a DB.

Maybe I'm answering my own question.

Okay, I understand at a high-level why databases are useful.

Right of the top of my head:

Too much data for/ so much data that a spreadsheet becomes unwieldy.
Multiple users - Data is updated by one, ready to use/view by all (really, I could argue that the software/ UI makes that easier).
Obviously warehouse/inventory/customer management.

When digging up old freeware/shareware in run into some database software, I've seen people talk about using a database for things like keeping track of their CD collection/Video Movie tapes/DVDs...

I always find myself asking, how big would insert-whatever-collection would have to be to make a database worth the while as compared with a simple spreadsheet? How many bits of information would I have to be recording for each, say CD, to make it worth the while. Yeah, I'm familiar with the argument that a spreadsheet is technically a database... Who knows, maybe someone likes interface of some particular database better. I guess having a UI where you're filling out info on a particular, again say CD, might be 'less confusing' or 'harder to mess up' than trying to keep the following entries in a spreadsheet row (or possibly, a column).

I hate leaving an open-ended question here, but I guess, in this case, I will.

Why, FOR PERSONAL USE, would someone choose a database over a simple spreadsheet? I can't see it.