> I wrote:
>> A database without integrity is NOT a database,
>> because to call a file a database
>> it MUST have some applyable integrity-rules, Nass Jo.
>>
>> You could even say that all files,
>> having usable content,
>> are databases,
>> so a corrupted database is not a database, Jo.
>
> Strange i always thought of a database as a set of relational
> records/datasets, the first databases was not multiuser and had no
> integrity rules?
I did not talk about multi-user, even while a database does not mind in
itself what user uses it. If you mean concurrent use, that even now largely
depends on the knowledge of the programmer.
> Nowadays they have.
Well No, a working database cannot exist without integrety rules.
Even a file with just a single number in it is a database, btw.
> A database is an organized collection of data.[1]
Why the [1]?
What would a disorganised collection of data look like?
Something without integrety rules, perhaps?
> It is a collection of
> schemas, tables, queries, reports, views, and other objects.
Not neccessarily, it is a collecion of one ore more pieces of data.
Even a file with just a single number in it is(/can be seen as) a database.
> I think you are wrong, it is the organisation of data into a tree by
> "threading" that constitute the database.
Well, I am reasonably sure to be right.
> The integrity and multiuser
> functionality come long after the first database.
After the third, perhaps? Nonsense.
> The database was about
> not needing empty properties in records, that was the original purpose
> "well and not have to read out data sequentially.
>
> Am I wrong?
Yes. You are confused by thinking a special type of database,
[perhaps the ones under MS-ACCESS or SQL-server] that are called "relational
databases", are the only ones, however for instance huge distributed
databases of Google are necessarily not of that kind.
A database is JUST a collecion of one ore more pieces of data.
==========
Sometimes, when I need a limited set of changing data,
perhaps only one record with a number of fields,
it pays of to use a serverside file using "Scripting.FileSystemObject"
under ASP, bypassing the overhead of a dedicated database-engine,
and for instance being able to save dayly database-copies without much
memory-impact.
Yes then I miss the concurrent multiuser safety, but also the always looming
database deadlock.