O/T: Nibbling on an Apple

On Fri, 09 Aug 2013 12:07:37 -0400, nospam
wrote:

In article , Eric Stevens
wrote:

There is a 'within the blob' if the blob is used to store a gazillion
photographs.

there could be but there doesn't have to be.

you need to stop being fixated on files being the sole solution to the
world's problems.

I did in another post. Where computers in the future wouldn't deal with
file systems and instead make queries for data to a database.

Which ultimately must point to recoverable files (or whatever you like
to call them).

if they're not files they shouldn't be called files.

Do you know of an alternative name?

In the hope that eventually you will understand them and be able to
answer them.

one hopes that about you.
--

Regards,

Eric Stevens

On Fri, 09 Aug 2013 12:07:39 -0400, nospam
wrote:

In article , Eric Stevens
wrote:

You are relying on a higher level language (SQL) without giving any
thought as to the actions triggered inside the computer as a result.
You seem to regard it all as a black box below the SQL level. Well, it
isn't just a black box.

it can be treated as a black box.

what matters is if you get the correct data. how it works internally is
not important, except to those writing sql engines.

How it works is less important than what it is doing. That is the most
important thing to those writing SQL engines.
--

Regards,

Eric Stevens

On Fri, 09 Aug 2013 12:25:12 +0200, Sandman wrote:

In article ,
Eric Stevens wrote:

The blob just gets pushed into storage, over-writing anything that may
already be there? Don't be silly.

who said anything about overwriting data?

How do you decide where to write the blob so as to avoid overwriting
data.

Given the fact that the BLOB is a field type in a table in a database,
*I* don't decide anything. I just write the DB record and the DB engine
write it to the DBSM, which may or may not be stored in a file in a file
system.

What are we up to - 25 times this has been explained to you?

This is the first time you have allowed yourself to use the word
'file' in this context. Files imply a file management system, which is
about where I came in.
--

Regards,

Eric Stevens

On Fri, 09 Aug 2013 12:07:40 -0400, nospam
wrote:

In article , Eric Stevens
wrote:

The blob just gets pushed into storage, over-writing anything that may
already be there? Don't be silly.

who said anything about overwriting data?

How do you decide where to write the blob so as to avoid overwriting
data.

it's done for you automatically. computers are cool, that way.

So there is (file containing) blob management system.

Just tell mme one way that the designer locate and recover the desired
data from within the blob.

a map.

And how is the map managed?

based on your questions, it's clear you don't understand what i'm
talking about.

I understand very well. I'm trying to explore the depths of your
understanding.
--

Regards,

Eric Stevens

On Fri, 09 Aug 2013 12:09:02 +0200, Sandman wrote:

In article ,
Eric Stevens wrote:

You keep hinting at these 'something elses'. What are they?

BLOB.

How does the computer determine where the blob can be stored

The *computer* doesn't determine anything. It is done in the DB engine.

So the DB engine is managing the contents of the disk?

No. It is managing the content of the database, where the BLOB data is
saved.

I've been trying to get you to admit that. If the DB engine is not
managing the contents of the disk then something else must be.

Step out of this thread. You do not have the prerequisite knowledge to
participate.

and how is data stored in the blob and how is it located for later
recovery?

1. insert into user.images (image) values ('BLOB DATA');

2. select image from user.images where id = 1234;

It's all magic.

To you, perhaps.

You have no idea of how your "select image from user.images where id
= 1234" goes about locating data on the disc from within the blob.

There is no "within the blob", stop using words you don't understand.
The BLOB is a field in a table in a database in a database storage. The
database storage can be a file or it can be a logical volume. This is
the twentieth time I've told you this.

So the earlier suggestion (of nospams) that multiple photographs are
stored in a blob is not correct. That means there is no necessity to
locate individual photographs with a blob. All that is required is the
location of a particular blob containing the target photograph.

This requires a file/photograph management system for the database
containing the blob. Which is the point I have been trying to get to
since more or less the beginning.

--

Regards,

Eric Stevens

On Fri, 09 Aug 2013 12:07:41 -0400, nospam
wrote:

In article , Eric Stevens
wrote:

how it's stored internally is not relevant. it could be files, or it
could be something else.

You keep hinting at these 'something elses'. What are they?

BLOB.

How does the computer determine where the blob can be stored

The *computer* doesn't determine anything. It is done in the DB engine.

So the DB engine is managing the contents of the disk?

it could but that would be a very unusual implementation.

how does the computer discover from where the blob can be recovered

It doesn't. The computer is totally oblivious to the existence of the
data.

and how is data stored in the blob and how is it located for later
recovery?

1. insert into user.images (image) values ('BLOB DATA');

2. select image from user.images where id = 1234;

It's all magic. You have no idea of how your "select image from
user.images where id = 1234" goes about locating data on the disc from
within the blob.

why does that matter?

It does seem as though you may not have thought about this. Is this
the reason that you persistently failed to realise that databases need
file management systems also? Note I am talking of files in the sense
of the photographic images which make up the blobs.

Not a very deep thinker, are you?

you certainly aren't.

to you everything is a file.

What else do you call the collection of bits which make up a file?
--

Regards,

Eric Stevens

On Fri, 09 Aug 2013 12:07:42 -0400, nospam
wrote:

In article , Eric Stevens
wrote:

the database and how information is stored is up to the app that
maintains it. it does not need a file system.

The database is part of the app's file system.

just what do you think a file system is?

if the app isn't indexing files, then there need not be a file system.

it only needs to know how the data is structured.

And that isn't a file (management) system?

definitely not. it's a data structure.

Plus, as explained above, the database can exist on the volume without
a
file system.

Your explanation above made use of the words "file system". You have
at last conceded the bleeding obvious and I think I will give up at
this point.

best you do, since you are fixated on files and can't see past that.

I am using file in the sense of discrete packets of coherent data.

a packet of data is not a file.

Now you are construing 'packet' as in TCIP.

no i'm not.

first of all it's tcp/ip, not tcip (you can't even get that much
right), and although tcp uses packets, that's not the only type of
packets that exist. that much should be obvious, but apparently not.

packets have a certain meaning and you are confusing it with files. to
you, everything is a file.

you really haven't much of a clue with this stuff.

Well you tell me a better name for the collection of bits which make
up a photograph.
--

Regards,

Eric Stevens

On Fri, 09 Aug 2013 12:06:34 +0200, Sandman wrote:

In article ,
Eric Stevens wrote:

So what. That a database can work without a file system was your (and
nospam's) claim. Please explain it.

How many times more until you understand it?

The database storage is loaded as a block level device directly from a
volume - without an intermediate file system, because the volume is the
data storage. There is no file system, no paths, no directories. There
is just a data storage.

This is the fifth time I've written the exact same words. When will you
comprehend them?

When you explain how specific data items are identified and recovered.

Ok, for the fourth time:

select * from user.images where id = 1234;

How many more times do I need to do it?

If I asked you how to make a pork pie, would you answer 'I would tell
the cook to do it'.

Now you have confirmed what I have always know: you have to have a
file system.

NO YOU DO NOT. See above. You have to separate between when I'm talking
about how things are done on the iPad and what restrictions there
*ISN'T* on a database.

1. The iPad has a file system
2. A database does not REQUIRE a file system (depending on the DB
software)
3. The actual data does not NEED to be kept in files in a file system.

True, but it can't function without a file management system.

Yes. It. Can. Stop claiming things about things you know nothing about.

Incorrect. Putting a photo in an album changes NOTHING in the file
system.

Then why bother putting the photo in the album?

For organization, Einstein.

But if putting the photograph in the system doesn't change anything,
isn't the system already organised?

Step out of this thread. You do not have the prerequisite knowledge to
participate.
--

Regards,

Eric Stevens

On Fri, 09 Aug 2013 12:22:30 +0200, Sandman wrote:

In article ,
Eric Stevens wrote:

MySQL, Oracle, jSQL, Postgres and probably a lot more can use block
level devices for DB storage.

And how do they identify particular data when they want to recover it?

Internally.

Look. whether or not the DB use a file system or not - data lookup is
done *in the DBMS*.

Is that not a file management system (bearing in mind that we have no
better word than file to describe the collection of bits which make up
a photograph).

When you execute this:

select name from usenet.trolls order by rank limit 1

And get this result:

"Eric Steven"

The file system is never used. This all happens inside the DBMS which
stores the DB either as a file (using the file system) **OR** as a R/W
block device on a logical volume.

How it finds your name from the database doesn't include the file system
in either of those cases. The file system CAN NOT help the database find
its data.

Except the database has its own internal file system.


Your question is like claiming that Microsoft Word is utilizing the file
system to find the fourth paragraph in a letter you're currently
writing, as if the file system would have any idea about paragraphs in
the document that may or may not even be stored IN the file system.

Here's a mind exploder for you, Eric; There are databases that are kept
ENTIRELY in RAM! Yes, this is true - they are created in RAM on the fly,
managed on the fly, and not ever saved to disk! My god, you're thinking,
how could a database ever exist without a file system holding its
hand????

You're hilarious.

You are stuck with only the one understanding of file system.
--

Regards,

Eric Stevens

On Fri, 09 Aug 2013 12:07:46 -0400, nospam
wrote:

In article , Eric Stevens
wrote:

i don't know what your fixation on files is, but files are not the only
way to do things.

Tell me a database which doesn't use files.

anything that uses core data.

http://www.cocoawithlove.com/2010/02...-data-and.html

"The Core Data Programming Guide clearly states that Core Data is
not a database ... "

i see you can google. if you actually read the article you'd see that
the differences aren't actually relevant to this discussion. core data
might technically not be a 'database' but it's often used as one.

And so too is Excel.

also, learning core data is a bit more involved than skimming a page
you found on google, but here's another page about it:

http://en.wikipedia.org/wiki/Core_Data
Core Data describes data with a high level data model expressed in
terms of entities and their relationships plus fetch requests that
retrieve entities meeting specific criteria. Code can retrieve and
manipulate this data on a purely object level without having to worry
about the details of storage and retrieval.

Yep.
--

Regards,

Eric Stevens