NoSQL Movement?

Juan Pedro Bolivar Puente magnicida at gmail.com
Fri Mar 5 10:37:04 CET 2010


On 04/03/10 19:52, ccc31807 wrote:
> On Mar 4, 11:51 am, Juan Pedro Bolivar Puente <magnic... at gmail.com>
> wrote:
>> No, relations are data.
> 
> This depends on your definition of 'data.' I would say that
> relationships is information gleaned from the data.
> 
>> "Data is data" says nothing. Data is
>> information.
> 
> To me, data and information are not the same thing, and in particular,
> data is NOT information. To me, information consists of the sifting,
> sorting, filtering, and rearrangement of data that can be useful in
> completing some task. As an illustration, consider some very large
> collection of ones and zeros -- the information it contains depends on
> whether it's views as a JPEG, an EXE, XML, WAV, or other sort of
> information processing device. Whichever way it's processed, the
> 'data' (the ones and zeros) stay the same, and do not constitute
> 'information' in their raw state.
> 
>> Actually, all data are relations: relating /values/ to
>> /properties/ of /entities/. Relations as understood by the "relational
>> model" is nothing else but assuming that properties and entities are
>> first class values of the data system and the can also be related.
> 
> Well, this sort of illustrates my point. The 'values' of 'properties'
> relating to specific 'entities' depends on how one processes the data,
> which can be processed various ways. For example, 10000001 can either
> be viewed as the decimal number 65 or the alpha character 'A' but the
> decision as to how to view this value isn't inherent in the data
> itself, but only as an artifact of our use of the data to turn it into
> information.
> 

Well, it depends as you said on the definition of information; actually
your definition of data fits into the information-theorical definition
of information as sequence of symbols... But I understand that in other
context /information/ can also mean the next level of abstraction on top
of /data/, in the same way as /knowledge/ is the next level of
abstraction on top of information; lets ground or basis on that.

In any case, your definition and George's still support my point of view
where relations are data: they are stored in the computer as a sequence
of ones and zeroes and is indistinguishable from any other thing in the
data space in that sense. Of course, it is a key data to be able to
recover information and specially to add new information consistently to
the data storage... That SQL includes special syntax for manipulating
relations should not hide this fact; and one can still query the
relational information in the same way one would query non-relational
data in most DBMS anyway...

Anyway I'm sorry for drifting the conversation away... Going back to the
main topic, I agree with the general view on this thread that relational
databases (information-bases ? ;) and non-relational ones are there to
do some different jobs. It is just by carefully examining a problem that
we can define which one fits it better; with relational databases having
the clear advantage that is mathematically grounded basis makes its
fitness for most problems quite clear, while the preference for
non-relational systems is a more technical and empirical problem of the
trade-offs of consistency vs scalability and so on.

JP




More information about the Python-list mailing list