Hi all,

please i have an array (for example; $x = [23, how, this,56, you,
nice])

 I want to store it in a mysql database as a SINGLE RECORD  such that
i can access it as and array. I don't know what DATA TYPE to use.

any sugesstion is welcomed.

kevid:

>Hi all,

Hi you,

>
>please i have an array (for example; $x = [23, how, this,56, you,
>nice])
>
> I want to store it in a mysql database as a SINGLE RECORD  such that
>i can access it as and array. 

Sounds like a silly idea, but there's hardly a way to offer better
information, since you don't give any background.
Anyway:

> I don't know what DATA TYPE to use.

Assuming you're using PHP, simply store as a VARCHAR and use implode()
and explode() to convert array to string and back.


-- 
Erick

Erick T. Barkhuis wrote:
> kevid:

>> please i have an array (for example; $x = [23, how, this,56, you,
>> nice])
>>
>> I want to store it in a mysql database as a SINGLE RECORD  such that
>> i can access it as and array. 
> 
> Sounds like a silly idea, but there's hardly a way to offer better
> information, since you don't give any background.


I have to say I agree with Erick.


>> I don't know what DATA TYPE to use.
> 
> Assuming you're using PHP, simply store as a VARCHAR and use implode()
> and explode() to convert array to string and back.

I would suggest serialize/unserialized instead of implode/explode
www.php.net/manual/en/function.serialize.php
www.php.net/manual/en/function.unserialize.php

This works on multi dimensional arrays, objects and so on, wile imploding and
exploding will just work on single dimension arrays with just int, float and
string content in those cells and you don't keep cell names.


-- 

  //Aho

J.O. Aho:

>Erick T. Barkhuis wrote:
>> kevid:
>
>>> please i have an array (for example; $x = [23, how, this,56, you,
>>> nice])
 
>> Assuming you're using PHP, simply store as a VARCHAR and use
>>implode()  and explode() to convert array to string and back.
>
>I would suggest serialize/unserialized 
>This works on multi dimensional arrays, objects and so on, wile
>imploding and exploding will just work on single dimension arrays
>with just int, float and string content in those cells and you don't
>keep cell names.

All true, but if OP really showed a significant example, then he
doesn't have field names, and he apparently only uses INTs and strings
(where I'm not sure about the strings, because quotes are missing).

Anyway, I wonder why OP wants to use a MySql database at all...


-- 
Erick

kevid wrote:
> Hi all,
> 
> please i have an array (for example; $x = [23, how, this,56, you,
> nice])
> 
>  I want to store it in a mysql database as a SINGLE RECORD  such that
> i can access it as and array. I don't know what DATA TYPE to use.
> 
> any sugesstion is welcomed.
> 

I also agree - a bad idea.  There is no array data type in MySQL (or any 
SQL database) because it violates the 1NF of database normalization.

Normalize your database and store the data properly.  It will cause you 
much less trouble in the long run.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On 28 mar, 16:00, Jerry Stuckle <jstuck...@attglobal.net> wrote:
[...]
> I also agree - a bad idea. =A0There is no array data type in MySQL (or an=
y
> SQL database) because it violates the 1NF of database normalization.
>

I also dislike the concept of array, but at least Postgres supports
it:

http://www.postgresql.org/docs/8.0/interactive/arrays.html


> Normalize your database and store the data properly. =A0It will cause you
> much less trouble in the long run.

I totally agree.


/Lennart

[...]

>> please i have an array (for example; $x = [23, how, this,56, you,
>> nice])
>>
>>  I want to store it in a mysql database as a SINGLE RECORD  such that
>> i can access it as and array. I don't know what DATA TYPE to use.
>>
>> any sugesstion is welcomed.
>>
>
> I also agree - a bad idea.  There is no array data type in MySQL (or any 
> SQL database) because it violates the 1NF of database normalization.

Firebird supports arrays of types, even multi-dimensional ones...


-- 
With regards,

Martijn Tonies
Upscene Productions
http://www.upscene.com

Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and Firebird!

Database questions? Check the forum:
http://www.databasedevelopmentforum.com 

Martijn Tonies wrote:
>>> please i have an array (for example; $x = [23, how, this,56, you,
>>> nice])
>>>
>>>  I want to store it in a mysql database as a SINGLE RECORD  such that
>>> i can access it as and array. I don't know what DATA TYPE to use.
>>>
>>> any sugesstion is welcomed.
>>>
>> I also agree - a bad idea.  There is no array data type in MySQL (or any 
>> SQL database) because it violates the 1NF of database normalization.
> 
> Firebird supports arrays of types, even multi-dimensional ones...
> 
> 

I should have said SQL Standard databases.  It violates basic normalization.

There are all kinds of stupid extensions to some products.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

>>>> please i have an array (for example; $x = [23, how, this,56, you,
>>>> nice])
>>>>
>>>>  I want to store it in a mysql database as a SINGLE RECORD  such that
>>>> i can access it as and array. I don't know what DATA TYPE to use.
>>>>
>>>> any sugesstion is welcomed.
>>>>
>>> I also agree - a bad idea.  There is no array data type in MySQL (or any 
>>> SQL database) because it violates the 1NF of database normalization.
>>
>> Firebird supports arrays of types, even multi-dimensional ones...
>>
>>
>
> I should have said SQL Standard databases.  It violates basic 
> normalization.

It depends, really, I've seen good reasons to use arrays, but hey, don't 
expect
to query then in a WHERE clause etc...

> There are all kinds of stupid extensions to some products.

That's true ;-)



-- 
With regards,

Martijn Tonies
Upscene Productions
http://www.upscene.com

Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and Firebird!

Database questions? Check the forum:
http://www.databasedevelopmentforum.com 

Martijn Tonies wrote:
>>>>> please i have an array (for example; $x = [23, how, this,56, you,
>>>>> nice])
>>>>>
>>>>>  I want to store it in a mysql database as a SINGLE RECORD  such that
>>>>> i can access it as and array. I don't know what DATA TYPE to use.
>>>>>
>>>>> any sugesstion is welcomed.
>>>>>
>>>> I also agree - a bad idea.  There is no array data type in MySQL (or any 
>>>> SQL database) because it violates the 1NF of database normalization.
>>> Firebird supports arrays of types, even multi-dimensional ones...
>>>
>>>
>> I should have said SQL Standard databases.  It violates basic 
>> normalization.
> 
> It depends, really, I've seen good reasons to use arrays, but hey, don't 
> expect
> to query then in a WHERE clause etc...
>

No, it doesn't depend.  1NF clearly states on value per field 
(row/column intersection).

You are correct it's difficult to search for in a WHERE clause - which 
is exactly why it's there.

>> There are all kinds of stupid extensions to some products.
> 
> That's true ;-)
> 
> 
> 



-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Mar 31, 12:52=A0pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> Martijn Tonies wrote:
>
> > It depends, really, I've seen good reasons to use arrays, but hey, don'=
t
> > expect
> > to query then in a WHERE clause etc...
>
> No, it doesn't depend. =A01NF clearly states on value per field
> (row/column intersection).

Right, but an array can be treated as a value.  MySQL and other SQL
databases already support arrays of characters.

To be specific, 1NF requires that tables correspond to relations.
Each component of each tuple of a relation must be a single element of
the domain of that component.  If not, the table is not a relation and
the relational algebra doesn't apply to it.  However, the notion of
domain only requires that the equality relation be defined for the
elements of the domain.

>
> You are correct it's difficult to search for in a WHERE clause - which
> is exactly why it's there.

That is due to a lack of proper support for composite data types in
general, arrays in particular, and optimization concerns; not because
arrays are inherently incompatible with declarative queries.

However, I agree with the recommendations in this thread.  An array is
most likely the wrong solution and will lead to querying difficulties.

On 31 Mar, 15:46, Nilone <rea...@gmail.com> wrote:
> On Mar 31, 12:52=A0pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>
> > Martijn Tonies wrote:
>
> > > It depends, really, I've seen good reasons to use arrays, but hey, do=
n't
> > > expect
> > > to query then in a WHERE clause etc...
>
> > No, it doesn't depend. =A01NF clearly states on value per field
> > (row/column intersection).
>
> Right, but an array can be treated as a value. =A0MySQL and other SQL
> databases already support arrays of characters.

This is an interesting point. It can certainly depend on how, in a
particular circumstance, one defines a value.

For example, I can see the case for storing an object in a field for
later retrieval. The object may contain many properties, but is in
this case being treated as a single entity.

Captain Paralytic wrote:
> On 31 Mar, 15:46, Nilone <rea...@gmail.com> wrote:
>> On Mar 31, 12:52 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>
>>> Martijn Tonies wrote:
>>>> It depends, really, I've seen good reasons to use arrays, but hey, don't
>>>> expect
>>>> to query then in a WHERE clause etc...
>>> No, it doesn't depend.  1NF clearly states on value per field
>>> (row/column intersection).
>> Right, but an array can be treated as a value.  MySQL and other SQL
>> databases already support arrays of characters.
> 
> This is an interesting point. It can certainly depend on how, in a
> particular circumstance, one defines a value.
> 
> For example, I can see the case for storing an object in a field for
> later retrieval. The object may contain many properties, but is in
> this case being treated as a single entity.

Yes, Paul, but OO databases store the object as its individual parts, 
which can be searched.  For instance, an "employee" object would be 
stored as "id", "name", "department", etc.  One can still search 
"department" to get a list of individuals in that department.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Nilone wrote:
> On Mar 31, 12:52 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Martijn Tonies wrote:
>>
>>> It depends, really, I've seen good reasons to use arrays, but hey, don't
>>> expect
>>> to query then in a WHERE clause etc...
>> No, it doesn't depend.  1NF clearly states on value per field
>> (row/column intersection).
> 
> Right, but an array can be treated as a value.  MySQL and other SQL
> databases already support arrays of characters.
>

A string is not an array of characters.  Some languages handle them that 
way - but others handle them as two different types.

> To be specific, 1NF requires that tables correspond to relations.
> Each component of each tuple of a relation must be a single element of
> the domain of that component.  If not, the table is not a relation and
> the relational algebra doesn't apply to it.  However, the notion of
> domain only requires that the equality relation be defined for the
> elements of the domain.
> 

You're great at quoting - but do you really understand what it means? 
For those who aren't into academic jargon:

1. There's no top-to-bottom ordering to the rows.
2. There's no left-to-right ordering to the columns.
3. There are no duplicate rows.
4. Every row-and-column intersection contains exactly one value from the 
applicable domain (and nothing else).
5. All columns are regular [i.e. rows have no hidden components such as 
row IDs, object IDs, or hidden timestamps].

Note #4.  An array is not a single value in the application domain.

>> You are correct it's difficult to search for in a WHERE clause - which
>> is exactly why it's there.
> 
> That is due to a lack of proper support for composite data types in
> general, arrays in particular, and optimization concerns; not because
> arrays are inherently incompatible with declarative queries.
> 

But they are.  As noted above.

> However, I agree with the recommendations in this thread.  An array is
> most likely the wrong solution and will lead to querying difficulties.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Apr 1, 11:36=A0am, Captain Paralytic <paul_laut...@yahoo.com> wrote:
> On 31 Mar, 15:46, Nilone <rea...@gmail.com> wrote:
>
> > On Mar 31, 12:52=A0pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>
> > > Martijn Tonies wrote:
>
> > > > It depends, really, I've seen good reasons to use arrays, but hey, =
don't
> > > > expect
> > > > to query then in a WHERE clause etc...
>
> > > No, it doesn't depend. =A01NF clearly states on value per field
> > > (row/column intersection).
>
> > Right, but an array can be treated as a value. =A0MySQL and other SQL
> > databases already support arrays of characters.
>
> This is an interesting point. It can certainly depend on how, in a
> particular circumstance, one defines a value.
>
> For example, I can see the case for storing an object in a field for
> later retrieval. The object may contain many properties, but is in
> this case being treated as a single entity.

Yes and no.  If you're very careful about distinguishing the
attributes of the object (i.e. those properties which are essential to
the identity of the object) from predicates which classify and
describe the object, then yes.  My attitude is to equate an object
with only those attributes which identify it, so when I store a
customer ID in a field, I am, in fact, storing a customer object.

Properties such as an employee's name, department, salary, etc are
usually descriptive and not identifying.  They're properly viewed as
relations over the objects described, not as components of the object.

On Apr 1, 1:18=A0pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> Nilone wrote:
> > On Mar 31, 12:52 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> >> Martijn Tonies wrote:
>
> >>> It depends, really, I've seen good reasons to use arrays, but hey, do=
n't
> >>> expect
> >>> to query then in a WHERE clause etc...
> >> No, it doesn't depend. =A01NF clearly states on value per field
> >> (row/column intersection).
>
> > Right, but an array can be treated as a value. =A0MySQL and other SQL
> > databases already support arrays of characters.
>
> A string is not an array of characters. =A0Some languages handle them tha=
t
> way - but others handle them as two different types.

In the context of MySQL and SQL databases, I believe they are always
handled as arrays of characters, except in the presence of NULLs.

>
> > To be specific, 1NF requires that tables correspond to relations.
> > Each component of each tuple of a relation must be a single element of
> > the domain of that component. =A0If not, the table is not a relation an=
d
> > the relational algebra doesn't apply to it. =A0However, the notion of
> > domain only requires that the equality relation be defined for the
> > elements of the domain.
>
> You're great at quoting - but do you really understand what it means?

I believe I do, and that's not a quote.

>
> For those who aren't into academic jargon:
>
> 1. There's no top-to-bottom ordering to the rows.
> 2. There's no left-to-right ordering to the columns.
> 3. There are no duplicate rows.
> 4. Every row-and-column intersection contains exactly one value from the
> applicable domain (and nothing else).
> 5. All columns are regular [i.e. rows have no hidden components such as
> row IDs, object IDs, or hidden timestamps].
>
> Note #4. =A0An array is not a single value in the application domain.

It depends on the concepts of array, value and domain, which haven't
been clearly defined in this conversation.  I'm no expert at category
theory, so I hope the following makes sense.

For me, a value is an element of a domain in which the law of identity
holds, i.e. a value is always equal to itself and never to any other
value.  A domain can be defined algebraically or co-algebraically, and
I think this is the source of our disagreement.  I define arrays
algebraically (as a physical sequence of values from a single domain)
in which case it can derive its identity from its components and hence
an algebraic array of values is always a value too.

I don't see any reason to adopt a co-algebraic view in the context of
databases.  In particular, persistence of co-algebraic objects hasn't
been clearly defined, but it certainly isn't the representation of
objects in terms of their images in the co-domains of their methods.

Certainly, there may be reason to adopt such a view in the application
domain, but then let's speak of an indexed collection rather than an
array.  Similarly for strings, I would prefer to keep the name
"string" for the algebraic definition as an array of characters, and
use a different name for the objects of co-algebraic text-handling
classes - how about Text?  Alternatively, I've noticed a trend in some
languages to capitalize co-algebraic types and use lowercase for
algebraic types.

>
> >> You are correct it's difficult to search for in a WHERE clause - which
> >> is exactly why it's there.
>
> > That is due to a lack of proper support for composite data types in
> > general, arrays in particular, and optimization concerns; not because
> > arrays are inherently incompatible with declarative queries.
>
> But they are. =A0As noted above.
>
> > However, I agree with the recommendations in this thread. =A0An array i=
s
> > most likely the wrong solution and will lead to querying difficulties.
>
> --
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstuck...@attglobal.net
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Nilone wrote:
> On Apr 1, 1:18 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Nilone wrote:
>>> On Mar 31, 12:52 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>> Martijn Tonies wrote:
>>>>> It depends, really, I've seen good reasons to use arrays, but hey, don't
>>>>> expect
>>>>> to query then in a WHERE clause etc...
>>>> No, it doesn't depend.  1NF clearly states on value per field
>>>> (row/column intersection).
>>> Right, but an array can be treated as a value.  MySQL and other SQL
>>> databases already support arrays of characters.
>> A string is not an array of characters.  Some languages handle them that
>> way - but others handle them as two different types.
> 
> In the context of MySQL and SQL databases, I believe they are always
> handled as arrays of characters, except in the presence of NULLs.
>

No, they are handled as the SQL types CHAR and VARCHAR.  This is not the 
same as an array of characters; MySQL (and the SQL standard) do not 
support arrays.

>>> To be specific, 1NF requires that tables correspond to relations.
>>> Each component of each tuple of a relation must be a single element of
>>> the domain of that component.  If not, the table is not a relation and
>>> the relational algebra doesn't apply to it.  However, the notion of
>>> domain only requires that the equality relation be defined for the
>>> elements of the domain.
>> You're great at quoting - but do you really understand what it means?
> 
> I believe I do, and that's not a quote.
> 
>> For those who aren't into academic jargon:
>>
>> 1. There's no top-to-bottom ordering to the rows.
>> 2. There's no left-to-right ordering to the columns.
>> 3. There are no duplicate rows.
>> 4. Every row-and-column intersection contains exactly one value from the
>> applicable domain (and nothing else).
>> 5. All columns are regular [i.e. rows have no hidden components such as
>> row IDs, object IDs, or hidden timestamps].
>>
>> Note #4.  An array is not a single value in the application domain.
> 
> It depends on the concepts of array, value and domain, which haven't
> been clearly defined in this conversation.  I'm no expert at category
> theory, so I hope the following makes sense.
> 

An array in ANY language is a set of zero or more items of the same 
type, which can be individually accessed through some indexing method. 
Note that in all languages, arrays can contain more than one value.

> For me, a value is an element of a domain in which the law of identity
> holds, i.e. a value is always equal to itself and never to any other
> value.  A domain can be defined algebraically or co-algebraically, and
> I think this is the source of our disagreement.  I define arrays
> algebraically (as a physical sequence of values from a single domain)
> in which case it can derive its identity from its components and hence
> an algebraic array of values is always a value too.
> 

You can define them any way you want.  But they do not match the rest of 
the world's definition.

> I don't see any reason to adopt a co-algebraic view in the context of
> databases.  In particular, persistence of co-algebraic objects hasn't
> been clearly defined, but it certainly isn't the representation of
> objects in terms of their images in the co-domains of their methods.
> 

As I said - the rest of the world does not agree with your definition.

> Certainly, there may be reason to adopt such a view in the application
> domain, but then let's speak of an indexed collection rather than an
> array.  Similarly for strings, I would prefer to keep the name
> "string" for the algebraic definition as an array of characters, and
> use a different name for the objects of co-algebraic text-handling
> classes - how about Text?  Alternatively, I've noticed a trend in some
> languages to capitalize co-algebraic types and use lowercase for
> algebraic types.
> 

Again - a string is not an array of characters!  It is a different data 
type.  So the rest of your analogy rapidly falls apart.  And an index 
collection is an array - no matter what the internal implementation is.

As for coding styles - completely immaterial to this discussion.



-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On 1 Apr, 16:39, Jerry Stuckle <jstuck...@attglobal.net> wrote:
[...]
> No, they are handled as the SQL types CHAR and VARCHAR. =A0This is not th=
e
> same as an array of characters; MySQL (and the SQL standard) do not
> support arrays.

Arrays where introduced in sql99 together with other questionable
constructs such as ref type.

/Lennart

[...]

Lennart wrote:
> On 1 Apr, 16:39, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> [...]
>> No, they are handled as the SQL types CHAR and VARCHAR.  This is not the
>> same as an array of characters; MySQL (and the SQL standard) do not
>> support arrays.
> 
> Arrays where introduced in sql99 together with other questionable
> constructs such as ref type.
> 
> /Lennart
> 
> [...]
> 

Yea, I forgot about that.  Fortunately, it hasn't been implemented by 
every vendor yet - and so far I have yet to see any professional DB 
designer use it.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Apr 1, 4:39=A0pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> Nilone wrote:
> > On Apr 1, 1:18 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> >> A string is not an array of characters. =A0Some languages handle them =
that
> >> way - but others handle them as two different types.
>
> > In the context of MySQL and SQL databases, I believe they are always
> > handled as arrays of characters, except in the presence of NULLs.
>
> No, they are handled as the SQL types CHAR and VARCHAR. =A0This is not th=
e
> same as an array of characters; MySQL (and the SQL standard) do not
> support arrays.

Yes, I agree in the sense you're describing it, but look behind the
curtain.  The various string functions like CHAR(), CHAR_LENGTH(),
CONCAT(), INSERT(), INSTR(), LEFT(), etc clearly describe these types
as sequences of characters.

However, I must also relax my position.  Certain features of these
types, like the removal of trailing spaces and case insensitive
comparisons, contradict the algebraic view.  Still, I think the
semantics of CHAR and VARCHAR are predominantly based on algebraic
arrays of characters.

>
>
>
> >>> To be specific, 1NF requires that tables correspond to relations.
> >>> Each component of each tuple of a relation must be a single element o=
f
> >>> the domain of that component. =A0If not, the table is not a relation =
and
> >>> the relational algebra doesn't apply to it. =A0However, the notion of
> >>> domain only requires that the equality relation be defined for the
> >>> elements of the domain.
> >> You're great at quoting - but do you really understand what it means?
>
> > I believe I do, and that's not a quote.
>
> >> For those who aren't into academic jargon:
>
> >> 1. There's no top-to-bottom ordering to the rows.
> >> 2. There's no left-to-right ordering to the columns.
> >> 3. There are no duplicate rows.
> >> 4. Every row-and-column intersection contains exactly one value from t=
he
> >> applicable domain (and nothing else).
> >> 5. All columns are regular [i.e. rows have no hidden components such a=
s
> >> row IDs, object IDs, or hidden timestamps].
>
> >> Note #4. =A0An array is not a single value in the application domain.
>
> > It depends on the concepts of array, value and domain, which haven't
> > been clearly defined in this conversation. =A0I'm no expert at category
> > theory, so I hope the following makes sense.
>
> An array in ANY language is a set of zero or more items of the same
> type, which can be individually accessed through some indexing method.

I'm sorry, that definition leaves much to be desired.  Instead of a
set, let's talk of a sequence - sets are unordered and can't contain
the same element twice.  What do you mean by items - for example, if
two slots in an array in RAM contain the same binary representation,
are they the same item represented twice, or separate items with the
same state?  What is a type, and can items belong to multiple types or
not?  When you talk about accessing the items, do you allow the
contents of the array to be changed?  If so, is the array still the
same array after modification?

> Note that in all languages, arrays can contain more than one value.

An array can also BE a single value.  Take for example the arrays of
bits that make up the numeric types in MySQL.  In general, an array of
n values of a domain defines a single value in the n-dimensional
cartesian product of that domain.

Why does it matter?  Because I want my database to properly support
geometric points and shapes, addresses, trees, intervals, and so on.
A 2D point is one value with two components, not two values.  Proper
support for the algebraic nature of arrays, tuples, and other
constructs would allow complex data to be represented more easily and
would simplify maintenance and queries.

>
> > For me, a value is an element of a domain in which the law of identity
> > holds, i.e. a value is always equal to itself and never to any other
> > value. =A0A domain can be defined algebraically or co-algebraically, an=
d
> > I think this is the source of our disagreement. =A0I define arrays
> > algebraically (as a physical sequence of values from a single domain)
> > in which case it can derive its identity from its components and hence
> > an algebraic array of values is always a value too.
>
> You can define them any way you want. =A0But they do not match the rest o=
f
> the world's definition.

Please explain.  If you have a better definition, I would appreciate
it if you would provide it, or at least be explicit about the problems
with mine, so that I can learn and improve.

>
> > I don't see any reason to adopt a co-algebraic view in the context of
> > databases. =A0In particular, persistence of co-algebraic objects hasn't
> > been clearly defined, but it certainly isn't the representation of
> > objects in terms of their images in the co-domains of their methods.
>
> As I said - the rest of the world does not agree with your definition.

As the spokesman for the rest of the world, certainly you can provide
more info than that?  ;)

>
> > Certainly, there may be reason to adopt such a view in the application
> > domain, but then let's speak of an indexed collection rather than an
> > array. =A0Similarly for strings, I would prefer to keep the name
> > "string" for the algebraic definition as an array of characters, and
> > use a different name for the objects of co-algebraic text-handling
> > classes - how about Text? =A0Alternatively, I've noticed a trend in som=
e
> > languages to capitalize co-algebraic types and use lowercase for
> > algebraic types.
>
> Again - a string is not an array of characters! =A0It is a different data
> type.

See above.

> =A0So the rest of your analogy rapidly falls apart. =A0And an index
> collection is an array - no matter what the internal implementation is.

If you access the same slot of an array twice, and get different
results, are you in fact working with an array?  Is a modifiable array
an array, and is it the same array after modification?  Do you allow
nulls in arrays, and if so, how do such arrays relate to arrays
without nulls?

Thanks for your responses, Jerry.  It's a complex topic, and any
feedback allows me to refine my thoughts.

On Thu, 01 Apr 2010 07:14:36 -0400, Jerry Stuckle wrote:
> Captain Paralytic wrote:
>> On 31 Mar, 15:46, Nilone <rea...@gmail.com> wrote:
>>> On Mar 31, 12:52 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>
>>>> Martijn Tonies wrote:
>>>>> It depends, really, I've seen good reasons to use arrays, but hey, don't
>>>>> expect
>>>>> to query then in a WHERE clause etc...
>>>> No, it doesn't depend.  1NF clearly states on value per field
>>>> (row/column intersection).
>>> Right, but an array can be treated as a value.  MySQL and other SQL
>>> databases already support arrays of characters.
>> 
>> This is an interesting point. It can certainly depend on how, in a
>> particular circumstance, one defines a value.
>> 
>> For example, I can see the case for storing an object in a field for
>> later retrieval. The object may contain many properties, but is in
>> this case being treated as a single entity.
>
> Yes, Paul, but OO databases store the object as its individual parts, 
> which can be searched.  For instance, an "employee" object would be 
> stored as "id", "name", "department", etc.  One can still search 
> "department" to get a list of individuals in that department.

Hmmm.. Are there OO databases that are not (and probably could not) be
implmented as abstractions on top of a run of the mill RDBMS? I mean
the descriptions of the thing sound like they're basically creating
"entities" out of a bunch of attributes stored in tables tied together
by some critial (perhaps hidden from the user as the often-presumed SQL
row number is hidden) "entity ID"...

-- 
Nay, God Himself will not save men against their wills.  -Locke

Peter H. Coffin wrote:
> On Thu, 01 Apr 2010 07:14:36 -0400, Jerry Stuckle wrote:
>> Captain Paralytic wrote:
>>> On 31 Mar, 15:46, Nilone <rea...@gmail.com> wrote:
>>>> On Mar 31, 12:52 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>>
>>>>> Martijn Tonies wrote:
>>>>>> It depends, really, I've seen good reasons to use arrays, but hey, don't
>>>>>> expect
>>>>>> to query then in a WHERE clause etc...
>>>>> No, it doesn't depend.  1NF clearly states on value per field
>>>>> (row/column intersection).
>>>> Right, but an array can be treated as a value.  MySQL and other SQL
>>>> databases already support arrays of characters.
>>> This is an interesting point. It can certainly depend on how, in a
>>> particular circumstance, one defines a value.
>>>
>>> For example, I can see the case for storing an object in a field for
>>> later retrieval. The object may contain many properties, but is in
>>> this case being treated as a single entity.
>> Yes, Paul, but OO databases store the object as its individual parts, 
>> which can be searched.  For instance, an "employee" object would be 
>> stored as "id", "name", "department", etc.  One can still search 
>> "department" to get a list of individuals in that department.
> 
> Hmmm.. Are there OO databases that are not (and probably could not) be
> implmented as abstractions on top of a run of the mill RDBMS? I mean
> the descriptions of the thing sound like they're basically creating
> "entities" out of a bunch of attributes stored in tables tied together
> by some critial (perhaps hidden from the user as the often-presumed SQL
> row number is hidden) "entity ID"...
> 

Yes and no.  While you *could* store an object in a non-OO database, the 
OO database provides tools to manage things such as derived classes.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Nilone wrote:
> On Apr 1, 4:39 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Nilone wrote:
>>> On Apr 1, 1:18 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>> A string is not an array of characters.  Some languages handle them that
>>>> way - but others handle them as two different types.
>>> In the context of MySQL and SQL databases, I believe they are always
>>> handled as arrays of characters, except in the presence of NULLs.
>> No, they are handled as the SQL types CHAR and VARCHAR.  This is not the
>> same as an array of characters; MySQL (and the SQL standard) do not
>> support arrays.
> 
> Yes, I agree in the sense you're describing it, but look behind the
> curtain.  The various string functions like CHAR(), CHAR_LENGTH(),
> CONCAT(), INSERT(), INSTR(), LEFT(), etc clearly describe these types
> as sequences of characters.
>

Which does not indicate they are an array of characters.  It just limits 
the maximum size of the field - just like a BLOB has a maximum limit, 
for instance.

> However, I must also relax my position.  Certain features of these
> types, like the removal of trailing spaces and case insensitive
> comparisons, contradict the algebraic view.  Still, I think the
> semantics of CHAR and VARCHAR are predominantly based on algebraic
> arrays of characters.
> 

No, they are based on strings.  Nothing more, nothing less.

>>
>>
>>>>> To be specific, 1NF requires that tables correspond to relations.
>>>>> Each component of each tuple of a relation must be a single element of
>>>>> the domain of that component.  If not, the table is not a relation and
>>>>> the relational algebra doesn't apply to it.  However, the notion of
>>>>> domain only requires that the equality relation be defined for the
>>>>> elements of the domain.
>>>> You're great at quoting - but do you really understand what it means?
>>> I believe I do, and that's not a quote.
>>>> For those who aren't into academic jargon:
>>>> 1. There's no top-to-bottom ordering to the rows.
>>>> 2. There's no left-to-right ordering to the columns.
>>>> 3. There are no duplicate rows.
>>>> 4. Every row-and-column intersection contains exactly one value from the
>>>> applicable domain (and nothing else).
>>>> 5. All columns are regular [i.e. rows have no hidden components such as
>>>> row IDs, object IDs, or hidden timestamps].
>>>> Note #4.  An array is not a single value in the application domain.
>>> It depends on the concepts of array, value and domain, which haven't
>>> been clearly defined in this conversation.  I'm no expert at category
>>> theory, so I hope the following makes sense.
>> An array in ANY language is a set of zero or more items of the same
>> type, which can be individually accessed through some indexing method.
> 
> I'm sorry, that definition leaves much to be desired.  Instead of a
> set, let's talk of a sequence - sets are unordered and can't contain
> the same element twice.  What do you mean by items - for example, if
> two slots in an array in RAM contain the same binary representation,
> are they the same item represented twice, or separate items with the
> same state?  What is a type, and can items belong to multiple types or
> not?  When you talk about accessing the items, do you allow the
> contents of the array to be changed?  If so, is the array still the
> same array after modification?
>

A sequence is not an array - and is immaterial to this discussion.  And 
array elements are individual values - what one array element contains 
is completely independent of any other array element.

>> Note that in all languages, arrays can contain more than one value.
> 
> An array can also BE a single value.  Take for example the arrays of
> bits that make up the numeric types in MySQL.  In general, an array of
> n values of a domain defines a single value in the n-dimensional
> cartesian product of that domain.
> 

As I said - an array contains ZERO OR MORE values.

> Why does it matter?  Because I want my database to properly support
> geometric points and shapes, addresses, trees, intervals, and so on.
> A 2D point is one value with two components, not two values.  Proper
> support for the algebraic nature of arrays, tuples, and other
> constructs would allow complex data to be represented more easily and
> would simplify maintenance and queries.
>

A point is not an array - although that is one way your program may 
implement a point.  There are other ways it could be implemented, also.

>>> For me, a value is an element of a domain in which the law of identity
>>> holds, i.e. a value is always equal to itself and never to any other
>>> value.  A domain can be defined algebraically or co-algebraically, and
>>> I think this is the source of our disagreement.  I define arrays
>>> algebraically (as a physical sequence of values from a single domain)
>>> in which case it can derive its identity from its components and hence
>>> an algebraic array of values is always a value too.
>> You can define them any way you want.  But they do not match the rest of
>> the world's definition.
> 
> Please explain.  If you have a better definition, I would appreciate
> it if you would provide it, or at least be explicit about the problems
> with mine, so that I can learn and improve.
> 

I have provided the standard definition of an array.

>>> I don't see any reason to adopt a co-algebraic view in the context of
>>> databases.  In particular, persistence of co-algebraic objects hasn't
>>> been clearly defined, but it certainly isn't the representation of
>>> objects in terms of their images in the co-domains of their methods.
>> As I said - the rest of the world does not agree with your definition.
> 
> As the spokesman for the rest of the world, certainly you can provide
> more info than that?  ;)
>

Do some homework - and see how the rest of the world defines arrays. 
They do not match your definition - but do mine.

>>> Certainly, there may be reason to adopt such a view in the application
>>> domain, but then let's speak of an indexed collection rather than an
>>> array.  Similarly for strings, I would prefer to keep the name
>>> "string" for the algebraic definition as an array of characters, and
>>> use a different name for the objects of co-algebraic text-handling
>>> classes - how about Text?  Alternatively, I've noticed a trend in some
>>> languages to capitalize co-algebraic types and use lowercase for
>>> algebraic types.
>> Again - a string is not an array of characters!  It is a different data
>> type.
> 
> See above.
> 

See above.

>>  So the rest of your analogy rapidly falls apart.  And an index
>> collection is an array - no matter what the internal implementation is.
> 
> If you access the same slot of an array twice, and get different
> results, are you in fact working with an array?  Is a modifiable array
> an array, and is it the same array after modification?  Do you allow
> nulls in arrays, and if so, how do such arrays relate to arrays
> without nulls?
>

Non Sequitur. Why would you get different results from the same array 
element, unless you have changed that element in between accesses?  As 
to being the same array - sure it's the same array.  Values do not 
identify the array.


> Thanks for your responses, Jerry.  It's a complex topic, and any
> feedback allows me to refine my thoughts.

No, it's actually quite a simple topic - which you are making complicated.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Apr 1, 7:25=A0pm, "Peter H. Coffin" <hell...@ninehells.com> wrote:
> On Thu, 01 Apr 2010 07:14:36 -0400, Jerry Stuckle wrote:
> > Captain Paralytic wrote:
> >> On 31 Mar, 15:46, Nilone <rea...@gmail.com> wrote:
> >>> On Mar 31, 12:52 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>
> >>>> Martijn Tonies wrote:
> >>>>> It depends, really, I've seen good reasons to use arrays, but hey, =
don't
> >>>>> expect
> >>>>> to query then in a WHERE clause etc...
> >>>> No, it doesn't depend. =A01NF clearly states on value per field
> >>>> (row/column intersection).
> >>> Right, but an array can be treated as a value. =A0MySQL and other SQL
> >>> databases already support arrays of characters.
>
> >> This is an interesting point. It can certainly depend on how, in a
> >> particular circumstance, one defines a value.
>
> >> For example, I can see the case for storing an object in a field for
> >> later retrieval. The object may contain many properties, but is in
> >> this case being treated as a single entity.
>
> > Yes, Paul, but OO databases store the object as its individual parts,
> > which can be searched. =A0For instance, an "employee" object would be
> > stored as "id", "name", "department", etc. =A0One can still search
> > "department" to get a list of individuals in that department.
>
> Hmmm.. Are there OO databases that are not (and probably could not) be
> implmented as abstractions on top of a run of the mill RDBMS?

Good question.  One can conceive of something like a coalgebraic or
bialgebraic database.  For those unfamiliar with category theory, the
difference between algebraic and coalgebraic objects is that algebraic
objects are mapped FROM (i.e. they are defined by a set of properties
that can be inspected, and equality is defined as equality of the
values of attributes), while coalgebraic objects are mapped TO (i.e.
they are defined by a class of behaviours, and there is no value
equality, only identity and behavioural equality).  Coalgebraic
objects don't have a fixed representation, and hence can't be
consistently decomposed to be stored as a set of attributes.  The only
way to represent one is to represent the function that constructs it,
which is the reason for serialization/deserialization in the OO
world.  It's still a hack, though - the correct solution would be to
support first-class functions at all levels from the logical
persistence layer to the objects themselves.

> I mean
> the descriptions of the thing sound like they're basically creating
> "entities" out of a bunch of attributes stored in tables tied together
> by some critial (perhaps hidden from the user as the often-presumed SQL
> row number is hidden) "entity ID"...

That's how I believe they do it, but I'll refrain from making
assertions since I don't have any experience with products of this
kind.

Nilone

--

"Explain yourself in any manner of way.  Disregard the little slips in
discourse.  Retract or reinforce anything you have offered, as best
serve your purpose.  Hear and examine everything in fairness, and if
you can find any flaw in any of your former concessions, or can think
of any subterfuge, any new distinction, colour, or comment whatsoever,
then produce it.  I am not for imposing any sense on your words: you
are at liberty to explain them as you please. Only, I beseech you,
make me understand something by them."

Paraphrased from the dialogue between Hylas and Philonous in
Berkeley's Three Dialogues.

On Apr 1, 7:38=A0pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> Nilone wrote:
> > On Apr 1, 4:39 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> >> Nilone wrote:
> >>> On Apr 1, 1:18 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> >>>> A string is not an array of characters. =A0Some languages handle the=
m that
> >>>> way - but others handle them as two different types.
> >>> In the context of MySQL and SQL databases, I believe they are always
> >>> handled as arrays of characters, except in the presence of NULLs.
> >> No, they are handled as the SQL types CHAR and VARCHAR. =A0This is not=
 the
> >> same as an array of characters; MySQL (and the SQL standard) do not
> >> support arrays.
>
> > Yes, I agree in the sense you're describing it, but look behind the
> > curtain. =A0The various string functions like CHAR(), CHAR_LENGTH(),
> > CONCAT(), INSERT(), INSTR(), LEFT(), etc clearly describe these types
> > as sequences of characters.
>
> Which does not indicate they are an array of characters. =A0It just limit=
s
> the maximum size of the field - just like a BLOB has a maximum limit,
> for instance.
>
> > However, I must also relax my position. =A0Certain features of these
> > types, like the removal of trailing spaces and case insensitive
> > comparisons, contradict the algebraic view. =A0Still, I think the
> > semantics of CHAR and VARCHAR are predominantly based on algebraic
> > arrays of characters.
>
> No, they are based on strings. =A0Nothing more, nothing less.

Please explain the difference.

>
>
>
>
>
> >>>>> To be specific, 1NF requires that tables correspond to relations.
> >>>>> Each component of each tuple of a relation must be a single element=
 of
> >>>>> the domain of that component. =A0If not, the table is not a relatio=
n and
> >>>>> the relational algebra doesn't apply to it. =A0However, the notion =
of
> >>>>> domain only requires that the equality relation be defined for the
> >>>>> elements of the domain.
> >>>> You're great at quoting - but do you really understand what it means=
?
> >>> I believe I do, and that's not a quote.
> >>>> For those who aren't into academic jargon:
> >>>> 1. There's no top-to-bottom ordering to the rows.
> >>>> 2. There's no left-to-right ordering to the columns.
> >>>> 3. There are no duplicate rows.
> >>>> 4. Every row-and-column intersection contains exactly one value from=
 the
> >>>> applicable domain (and nothing else).
> >>>> 5. All columns are regular [i.e. rows have no hidden components such=
 as
> >>>> row IDs, object IDs, or hidden timestamps].
> >>>> Note #4. =A0An array is not a single value in the application domain=
..
> >>> It depends on the concepts of array, value and domain, which haven't
> >>> been clearly defined in this conversation. =A0I'm no expert at catego=
ry
> >>> theory, so I hope the following makes sense.
> >> An array in ANY language is a set of zero or more items of the same
> >> type, which can be individually accessed through some indexing method.
>
> > I'm sorry, that definition leaves much to be desired. =A0Instead of a
> > set, let's talk of a sequence - sets are unordered and can't contain
> > the same element twice. =A0What do you mean by items - for example, if
> > two slots in an array in RAM contain the same binary representation,
> > are they the same item represented twice, or separate items with the
> > same state? =A0What is a type, and can items belong to multiple types o=
r
> > not? =A0When you talk about accessing the items, do you allow the
> > contents of the array to be changed? =A0If so, is the array still the
> > same array after modification?
>
> A sequence is not an array - and is immaterial to this discussion. =A0And
> array elements are individual values - what one array element contains
> is completely independent of any other array element.

I neglected to distinguish between array variables (i.e. an indexed
collection of memory slots of the same type) and array values (i.e. a
sequence of values of the same type).  Is that perhaps the source of
our disagreement?

I don't know how else to describe an array value than as a sequence of
values of the same type.  If sequence is not the right term, how
should I describe and understand it?

>
> >> Note that in all languages, arrays can contain more than one value.
>
> > An array can also BE a single value. =A0Take for example the arrays of
> > bits that make up the numeric types in MySQL. =A0In general, an array o=
f
> > n values of a domain defines a single value in the n-dimensional
> > cartesian product of that domain.
>
> As I said - an array contains ZERO OR MORE values.

I heard you.  Why can't I compose values from existing values?

>
> > Why does it matter? =A0Because I want my database to properly support
> > geometric points and shapes, addresses, trees, intervals, and so on.
> > A 2D point is one value with two components, not two values. =A0Proper
> > support for the algebraic nature of arrays, tuples, and other
> > constructs would allow complex data to be represented more easily and
> > would simplify maintenance and queries.
>
> A point is not an array - although that is one way your program may
> implement a point. =A0There are other ways it could be implemented, also.

I agree that it is one way to implement a point, but I don't see why
all the abstractions should be in my program.  Certainly, not only
programs use databases, people do too.  I want the dbms to recognize
and handle abstractions.  It already has some abstractions, like
strings and numbers and dates.  Why shouldn't I be able to add my own?

>
> >>> For me, a value is an element of a domain in which the law of identit=
y
> >>> holds, i.e. a value is always equal to itself and never to any other
> >>> value. =A0A domain can be defined algebraically or co-algebraically, =
and
> >>> I think this is the source of our disagreement. =A0I define arrays
> >>> algebraically (as a physical sequence of values from a single domain)
> >>> in which case it can derive its identity from its components and henc=
e
> >>> an algebraic array of values is always a value too.
> >> You can define them any way you want. =A0But they do not match the res=
t of
> >> the world's definition.
>
> > Please explain. =A0If you have a better definition, I would appreciate
> > it if you would provide it, or at least be explicit about the problems
> > with mine, so that I can learn and improve.
>
> I have provided the standard definition of an array.

And I find that definition vague and problematic.  I am trying to be
more specific and accurate.

>
> >>> I don't see any reason to adopt a co-algebraic view in the context of
> >>> databases. =A0In particular, persistence of co-algebraic objects hasn=
't
> >>> been clearly defined, but it certainly isn't the representation of
> >>> objects in terms of their images in the co-domains of their methods.
> >> As I said - the rest of the world does not agree with your definition.
>
> > As the spokesman for the rest of the world, certainly you can provide
> > more info than that? =A0;)
>
> Do some homework - and see how the rest of the world defines arrays.
> They do not match your definition - but do mine.

I have been doing homework, and a lot of it.  Popular opinion doesn't
prove you're right, if indeed the popular opinion agrees with you, but
deviation from the norm requires justification.  I believe I have that
justification, and have been expressing it.  Certainly, I've been a
lot more forthcoming with detail than you have.

>
> >>> Certainly, there may be reason to adopt such a view in the applicatio=
n
> >>> domain, but then let's speak of an indexed collection rather than an
> >>> array. =A0Similarly for strings, I would prefer to keep the name
> >>> "string" for the algebraic definition as an array of characters, and
> >>> use a different name for the objects of co-algebraic text-handling
> >>> classes - how about Text? =A0Alternatively, I've noticed a trend in s=
ome
> >>> languages to capitalize co-algebraic types and use lowercase for
> >>> algebraic types.
> >> Again - a string is not an array of characters! =A0It is a different d=
ata
> >> type.
>
> > See above.
>
> See above.
>
> >> =A0So the rest of your analogy rapidly falls apart. =A0And an index
> >> collection is an array - no matter what the internal implementation is=
..
>
> > If you access the same slot of an array twice, and get different
> > results, are you in fact working with an array? =A0Is a modifiable arra=
y
> > an array, and is it the same array after modification? =A0Do you allow
> > nulls in arrays, and if so, how do such arrays relate to arrays
> > without nulls?
>
> Non Sequitur. Why would you get different results from the same array
> element, unless you have changed that element in between accesses? =A0As
> to being the same array - sure it's the same array. =A0Values do not
> identify the array.

These answers correspond to an algebraic array variable in my point of
view.  I have no problem with that, but there is more that can be done
with an array than accessing its components by index, just like
there's more that can be done with a table than iterating over its
rows.

>
> > Thanks for your responses, Jerry. =A0It's a complex topic, and any
> > feedback allows me to refine my thoughts.
>
> No, it's actually quite a simple topic - which you are making complicated=
..

I'm just following the trail of breadcrumbs.  The complexity is
inherent to the concept of abstraction.

Nilone

--

Explain yourself in any manner of way.  Disregard the little slips in
discourse.  Retract or reinforce anything you have offered, as best
serve your purpose.  Hear and examine everything in fairness, and if
you can find any flaw in any of your former concessions, or can think
of any subterfuge, any new distinction, colour, or comment whatsoever,
then produce it.  I am not for imposing any sense on your words: you
are at liberty to explain them as you please. Only, I beseech you,
make me understand something by them.

Paraphrased from the dialogue between Hylas and Philonous in
Berkeley's Three Dialogues.

Nilone wrote:
> On Apr 1, 7:38 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Nilone wrote:
>>> On Apr 1, 4:39 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>> Nilone wrote:
>>>>> On Apr 1, 1:18 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>>>> A string is not an array of characters.  Some languages handle them that
>>>>>> way - but others handle them as two different types.
>>>>> In the context of MySQL and SQL databases, I believe they are always
>>>>> handled as arrays of characters, except in the presence of NULLs.
>>>> No, they are handled as the SQL types CHAR and VARCHAR.  This is not the
>>>> same as an array of characters; MySQL (and the SQL standard) do not
>>>> support arrays.
>>> Yes, I agree in the sense you're describing it, but look behind the
>>> curtain.  The various string functions like CHAR(), CHAR_LENGTH(),
>>> CONCAT(), INSERT(), INSTR(), LEFT(), etc clearly describe these types
>>> as sequences of characters.
>> Which does not indicate they are an array of characters.  It just limits
>> the maximum size of the field - just like a BLOB has a maximum limit,
>> for instance.
>>
>>> However, I must also relax my position.  Certain features of these
>>> types, like the removal of trailing spaces and case insensitive
>>> comparisons, contradict the algebraic view.  Still, I think the
>>> semantics of CHAR and VARCHAR are predominantly based on algebraic
>>> arrays of characters.
>> No, they are based on strings.  Nothing more, nothing less.
> 
> Please explain the difference.
>

Again - please see the definition of an array I have already posted.  I 
am not going to keep repeating myself because you won't read.

A string is not an array of characters, although it may be implement as 
such in *some* languages.  On others (including SQL), it is not.

>>
>>
>>
>>
>>>>>>> To be specific, 1NF requires that tables correspond to relations.
>>>>>>> Each component of each tuple of a relation must be a single element of
>>>>>>> the domain of that component.  If not, the table is not a relation and
>>>>>>> the relational algebra doesn't apply to it.  However, the notion of
>>>>>>> domain only requires that the equality relation be defined for the
>>>>>>> elements of the domain.
>>>>>> You're great at quoting - but do you really understand what it means?
>>>>> I believe I do, and that's not a quote.
>>>>>> For those who aren't into academic jargon:
>>>>>> 1. There's no top-to-bottom ordering to the rows.
>>>>>> 2. There's no left-to-right ordering to the columns.
>>>>>> 3. There are no duplicate rows.
>>>>>> 4. Every row-and-column intersection contains exactly one value from the
>>>>>> applicable domain (and nothing else).
>>>>>> 5. All columns are regular [i.e. rows have no hidden components such as
>>>>>> row IDs, object IDs, or hidden timestamps].
>>>>>> Note #4.  An array is not a single value in the application domain.
>>>>> It depends on the concepts of array, value and domain, which haven't
>>>>> been clearly defined in this conversation.  I'm no expert at category
>>>>> theory, so I hope the following makes sense.
>>>> An array in ANY language is a set of zero or more items of the same
>>>> type, which can be individually accessed through some indexing method.
>>> I'm sorry, that definition leaves much to be desired.  Instead of a
>>> set, let's talk of a sequence - sets are unordered and can't contain
>>> the same element twice.  What do you mean by items - for example, if
>>> two slots in an array in RAM contain the same binary representation,
>>> are they the same item represented twice, or separate items with the
>>> same state?  What is a type, and can items belong to multiple types or
>>> not?  When you talk about accessing the items, do you allow the
>>> contents of the array to be changed?  If so, is the array still the
>>> same array after modification?
>> A sequence is not an array - and is immaterial to this discussion.  And
>> array elements are individual values - what one array element contains
>> is completely independent of any other array element.
> 
> I neglected to distinguish between array variables (i.e. an indexed
> collection of memory slots of the same type) and array values (i.e. a
> sequence of values of the same type).  Is that perhaps the source of
> our disagreement?
> 

No.  A sequence is not an array.

> I don't know how else to describe an array value than as a sequence of
> values of the same type.  If sequence is not the right term, how
> should I describe and understand it?
>

An array is not a sequence.  A sequence is something entirely different. 
   Again, please see my definition of an array in earlier posts.

>>>> Note that in all languages, arrays can contain more than one value.
>>> An array can also BE a single value.  Take for example the arrays of
>>> bits that make up the numeric types in MySQL.  In general, an array of
>>> n values of a domain defines a single value in the n-dimensional
>>> cartesian product of that domain.
>> As I said - an array contains ZERO OR MORE values.
> 
> I heard you.  Why can't I compose values from existing values?
> 

I didn't say you couldn't.

>>> Why does it matter?  Because I want my database to properly support
>>> geometric points and shapes, addresses, trees, intervals, and so on.
>>> A 2D point is one value with two components, not two values.  Proper
>>> support for the algebraic nature of arrays, tuples, and other
>>> constructs would allow complex data to be represented more easily and
>>> would simplify maintenance and queries.
>> A point is not an array - although that is one way your program may
>> implement a point.  There are other ways it could be implemented, also.
> 
> I agree that it is one way to implement a point, but I don't see why
> all the abstractions should be in my program.  Certainly, not only
> programs use databases, people do too.  I want the dbms to recognize
> and handle abstractions.  It already has some abstractions, like
> strings and numbers and dates.  Why shouldn't I be able to add my own?
>

Because it's your program, and your data type, that's why.  You can 
implement your own abstractions if you wish - just like you can in 
languages.

>>>>> For me, a value is an element of a domain in which the law of identity
>>>>> holds, i.e. a value is always equal to itself and never to any other
>>>>> value.  A domain can be defined algebraically or co-algebraically, and
>>>>> I think this is the source of our disagreement.  I define arrays
>>>>> algebraically (as a physical sequence of values from a single domain)
>>>>> in which case it can derive its identity from its components and hence
>>>>> an algebraic array of values is always a value too.
>>>> You can define them any way you want.  But they do not match the rest of
>>>> the world's definition.
>>> Please explain.  If you have a better definition, I would appreciate
>>> it if you would provide it, or at least be explicit about the problems
>>> with mine, so that I can learn and improve.
>> I have provided the standard definition of an array.
> 
> And I find that definition vague and problematic.  I am trying to be
> more specific and accurate.
> 

It is specific and accurate.

>>>>> I don't see any reason to adopt a co-algebraic view in the context of
>>>>> databases.  In particular, persistence of co-algebraic objects hasn't
>>>>> been clearly defined, but it certainly isn't the representation of
>>>>> objects in terms of their images in the co-domains of their methods.
>>>> As I said - the rest of the world does not agree with your definition.
>>> As the spokesman for the rest of the world, certainly you can provide
>>> more info than that?  ;)
>> Do some homework - and see how the rest of the world defines arrays.
>> They do not match your definition - but do mine.
> 
> I have been doing homework, and a lot of it.  Popular opinion doesn't
> prove you're right, if indeed the popular opinion agrees with you, but
> deviation from the norm requires justification.  I believe I have that
> justification, and have been expressing it.  Certainly, I've been a
> lot more forthcoming with detail than you have.
>

It does when we are discussing the common definition of something.  The 
fact almost everyone else agrees on the definition makes it right.


>>>>> Certainly, there may be reason to adopt such a view in the application
>>>>> domain, but then let's speak of an indexed collection rather than an
>>>>> array.  Similarly for strings, I would prefer to keep the name
>>>>> "string" for the algebraic definition as an array of characters, and
>>>>> use a different name for the objects of co-algebraic text-handling
>>>>> classes - how about Text?  Alternatively, I've noticed a trend in some
>>>>> languages to capitalize co-algebraic types and use lowercase for
>>>>> algebraic types.
>>>> Again - a string is not an array of characters!  It is a different data
>>>> type.
>>> See above.
>> See above.
>>
>>>>  So the rest of your analogy rapidly falls apart.  And an index
>>>> collection is an array - no matter what the internal implementation is.
>>> If you access the same slot of an array twice, and get different
>>> results, are you in fact working with an array?  Is a modifiable array
>>> an array, and is it the same array after modification?  Do you allow
>>> nulls in arrays, and if so, how do such arrays relate to arrays
>>> without nulls?
>> Non Sequitur. Why would you get different results from the same array
>> element, unless you have changed that element in between accesses?  As
>> to being the same array - sure it's the same array.  Values do not
>> identify the array.
> 
> These answers correspond to an algebraic array variable in my point of
> view.  I have no problem with that, but there is more that can be done
> with an array than accessing its components by index, just like
> there's more that can be done with a table than iterating over its
> rows.
>

And only in your view.

>>> Thanks for your responses, Jerry.  It's a complex topic, and any
>>> feedback allows me to refine my thoughts.
>> No, it's actually quite a simple topic - which you are making complicated.
> 
> I'm just following the trail of breadcrumbs.  The complexity is
> inherent to the concept of abstraction.
> 
> Nilone
> 

Nope.  You're making a very simple topic hopelessly complicated.

> --
> 
> Explain yourself in any manner of way.  Disregard the little slips in
> discourse.  Retract or reinforce anything you have offered, as best
> serve your purpose.  Hear and examine everything in fairness, and if
> you can find any flaw in any of your former concessions, or can think
> of any subterfuge, any new distinction, colour, or comment whatsoever,
> then produce it.  I am not for imposing any sense on your words: you
> are at liberty to explain them as you please. Only, I beseech you,
> make me understand something by them.
> 
> Paraphrased from the dialogue between Hylas and Philonous in
> Berkeley's Three Dialogues.

.... which I couldn't care less about.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Apr 1, 10:43=A0pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> Nilone wrote:
> > On Apr 1, 7:38 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> >> Nilone wrote:
> >>> On Apr 1, 4:39 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> >>>> Nilone wrote:
> >>>>> On Apr 1, 1:18 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> >>>>>> A string is not an array of characters. =A0Some languages handle t=
hem that
> >>>>>> way - but others handle them as two different types.
> >>>>> In the context of MySQL and SQL databases, I believe they are alway=
s
> >>>>> handled as arrays of characters, except in the presence of NULLs.
> >>>> No, they are handled as the SQL types CHAR and VARCHAR. =A0This is n=
ot the
> >>>> same as an array of characters; MySQL (and the SQL standard) do not
> >>>> support arrays.
> >>> Yes, I agree in the sense you're describing it, but look behind the
> >>> curtain. =A0The various string functions like CHAR(), CHAR_LENGTH(),
> >>> CONCAT(), INSERT(), INSTR(), LEFT(), etc clearly describe these types
> >>> as sequences of characters.
> >> Which does not indicate they are an array of characters. =A0It just li=
mits
> >> the maximum size of the field - just like a BLOB has a maximum limit,
> >> for instance.
>
> >>> However, I must also relax my position. =A0Certain features of these
> >>> types, like the removal of trailing spaces and case insensitive
> >>> comparisons, contradict the algebraic view. =A0Still, I think the
> >>> semantics of CHAR and VARCHAR are predominantly based on algebraic
> >>> arrays of characters.
> >> No, they are based on strings. =A0Nothing more, nothing less.
>
> > Please explain the difference.
>
> Again - please see the definition of an array I have already posted. =A0I
> am not going to keep repeating myself because you won't read.
>
> A string is not an array of characters, although it may be implement as
> such in *some* languages. =A0On others (including SQL), it is not.
>
>
>
>
>
> >>>>>>> To be specific, 1NF requires that tables correspond to relations.
> >>>>>>> Each component of each tuple of a relation must be a single eleme=
nt of
> >>>>>>> the domain of that component. =A0If not, the table is not a relat=
ion and
> >>>>>>> the relational algebra doesn't apply to it. =A0However, the notio=
n of
> >>>>>>> domain only requires that the equality relation be defined for th=
e
> >>>>>>> elements of the domain.
> >>>>>> You're great at quoting - but do you really understand what it mea=
ns?
> >>>>> I believe I do, and that's not a quote.
> >>>>>> For those who aren't into academic jargon:
> >>>>>> 1. There's no top-to-bottom ordering to the rows.
> >>>>>> 2. There's no left-to-right ordering to the columns.
> >>>>>> 3. There are no duplicate rows.
> >>>>>> 4. Every row-and-column intersection contains exactly one value fr=
om the
> >>>>>> applicable domain (and nothing else).
> >>>>>> 5. All columns are regular [i.e. rows have no hidden components su=
ch as
> >>>>>> row IDs, object IDs, or hidden timestamps].
> >>>>>> Note #4. =A0An array is not a single value in the application doma=
in.
> >>>>> It depends on the concepts of array, value and domain, which haven'=
t
> >>>>> been clearly defined in this conversation. =A0I'm no expert at cate=
gory
> >>>>> theory, so I hope the following makes sense.
> >>>> An array in ANY language is a set of zero or more items of the same
> >>>> type, which can be individually accessed through some indexing metho=
d.
> >>> I'm sorry, that definition leaves much to be desired. =A0Instead of a
> >>> set, let's talk of a sequence - sets are unordered and can't contain
> >>> the same element twice. =A0What do you mean by items - for example, i=
f
> >>> two slots in an array in RAM contain the same binary representation,
> >>> are they the same item represented twice, or separate items with the
> >>> same state? =A0What is a type, and can items belong to multiple types=
 or
> >>> not? =A0When you talk about accessing the items, do you allow the
> >>> contents of the array to be changed? =A0If so, is the array still the
> >>> same array after modification?
> >> A sequence is not an array - and is immaterial to this discussion. =A0=
And
> >> array elements are individual values - what one array element contains
> >> is completely independent of any other array element.
>
> > I neglected to distinguish between array variables (i.e. an indexed
> > collection of memory slots of the same type) and array values (i.e. a
> > sequence of values of the same type). =A0Is that perhaps the source of
> > our disagreement?
>
> No. =A0A sequence is not an array.
>
> > I don't know how else to describe an array value than as a sequence of
> > values of the same type. =A0If sequence is not the right term, how
> > should I describe and understand it?
>
> An array is not a sequence. =A0A sequence is something entirely different=
..
> =A0 =A0Again, please see my definition of an array in earlier posts.
>
> >>>> Note that in all languages, arrays can contain more than one value.
> >>> An array can also BE a single value. =A0Take for example the arrays o=
f
> >>> bits that make up the numeric types in MySQL. =A0In general, an array=
 of
> >>> n values of a domain defines a single value in the n-dimensional
> >>> cartesian product of that domain.
> >> As I said - an array contains ZERO OR MORE values.
>
> > I heard you. =A0Why can't I compose values from existing values?
>
> I didn't say you couldn't.
>
> >>> Why does it matter? =A0Because I want my database to properly support
> >>> geometric points and shapes, addresses, trees, intervals, and so on.
> >>> A 2D point is one value with two components, not two values. =A0Prope=
r
> >>> support for the algebraic nature of arrays, tuples, and other
> >>> constructs would allow complex data to be represented more easily and
> >>> would simplify maintenance and queries.
> >> A point is not an array - although that is one way your program may
> >> implement a point. =A0There are other ways it could be implemented, al=
so.
>
> > I agree that it is one way to implement a point, but I don't see why
> > all the abstractions should be in my program. =A0Certainly, not only
> > programs use databases, people do too. =A0I want the dbms to recognize
> > and handle abstractions. =A0It already has some abstractions, like
> > strings and numbers and dates. =A0Why shouldn't I be able to add my own=
?
>
> Because it's your program, and your data type, that's why. =A0You can
> implement your own abstractions if you wish - just like you can in
> languages.
>
>
>
> >>>>> For me, a value is an element of a domain in which the law of ident=
ity
> >>>>> holds, i.e. a value is always equal to itself and never to any othe=
r
> >>>>> value. =A0A domain can be defined algebraically or co-algebraically=
, and
> >>>>> I think this is the source of our disagreement. =A0I define arrays
> >>>>> algebraically (as a physical sequence of values from a single domai=
n)
> >>>>> in which case it can derive its identity from its components and he=
nce
> >>>>> an algebraic array of values is always a value too.
> >>>> You can define them any way you want. =A0But they do not match the r=
est of
> >>>> the world's definition.
> >>> Please explain. =A0If you have a better definition, I would appreciat=
e
> >>> it if you would provide it, or at least be explicit about the problem=
s
> >>> with mine, so that I can learn and improve.
> >> I have provided the standard definition of an array.
>
> > And I find that definition vague and problematic. =A0I am trying to be
> > more specific and accurate.
>
> It is specific and accurate.
>
>
>
> >>>>> I don't see any reason to adopt a co-algebraic view in the context =
of
> >>>>> databases. =A0In particular, persistence of co-algebraic objects ha=
sn't
> >>>>> been clearly defined, but it certainly isn't the representation of
> >>>>> objects in terms of their images in the co-domains of their methods=
..
> >>>> As I said - the rest of the world does not agree with your definitio=
n.
> >>> As the spokesman for the rest of the world, certainly you can provide
> >>> more info than that? =A0;)
> >> Do some homework - and see how the rest of the world defines arrays.
> >> They do not match your definition - but do mine.
>
> > I have been doing homework, and a lot of it. =A0Popular opinion doesn't
> > prove you're right, if indeed the popular opinion agrees with you, but
> > deviation from the norm requires justification. =A0I believe I have tha=
t
> > justification, and have been expressing it. =A0Certainly, I've been a
> > lot more forthcoming with detail than you have.
>
> It does when we are discussing the common definition of something. =A0The
> fact almost everyone else agrees on the definition makes it right.
>
>
>
> >>>>> Certainly, there may be reason to adopt such a view in the applicat=
ion
> >>>>> domain, but then let's speak of an indexed collection rather than a=
n
> >>>>> array. =A0Similarly for strings, I would prefer to keep the name
> >>>>> "string" for the algebraic definition as an array of characters, an=
d
> >>>>> use a different name for the objects of co-algebraic text-handling
> >>>>> classes - how about Text? =A0Alternatively, I've noticed a trend in=
 some
> >>>>> languages to capitalize co-algebraic types and use lowercase for
> >>>>> algebraic types.
> >>>> Again - a string is not an array of characters! =A0It is a different=
 data
> >>>> type.
> >>> See above.
> >> See above.
>
> >>>> =A0So the rest of your analogy rapidly falls apart. =A0And an index
> >>>> collection is an array - no matter what the internal implementation =
is.
> >>> If you access the same slot of an array twice, and get different
> >>> results, are you in fact working with an array? =A0Is a modifiable ar=
ray
> >>> an array, and is it the same array after modification? =A0Do you allo=
w
> >>> nulls in arrays, and if so, how do such arrays relate to arrays
> >>> without nulls?
> >> Non Sequitur. Why would you get different results from the same array
> >> element, unless you have changed that element in between accesses? =A0=
As
> >> to being the same array - sure it's the same array. =A0Values do not
> >> identify the array.
>
> > These answers correspond to an algebraic array variable in my point of
> > view. =A0I have no problem with that, but there is more that can be don=
e
> > with an array than accessing its components by index, just like
> > there's more that can be done with a table than iterating over its
> > rows.
>
> And only in your view.
>
> >>> Thanks for your responses, Jerry. =A0It's a complex topic, and any
> >>> feedback allows me to refine my thoughts.
> >> No, it's actually quite a simple topic - which you are making complica=
ted.
>
> > I'm just following the trail of breadcrumbs. =A0The complexity is
> > inherent to the concept of abstraction.
>
> > Nilone
>
> Nope. =A0You're making a very simple topic hopelessly complicated.
>
> > --
>
> > Explain yourself in any manner of way. =A0Disregard the little slips in
> > discourse. =A0Retract or reinforce anything you have offered, as best
> > serve your purpose. =A0Hear and examine everything in fairness, and if
> > you can find any flaw in any of your former concessions, or can think
> > of any subterfuge, any new distinction, colour, or comment whatsoever,
> > then produce it. =A0I am not for imposing any sense on your words: you
> > are at liberty to explain them as you please. Only, I beseech you,
> > make me understand something by them.
>
> > Paraphrased from the dialogue between Hylas and Philonous in
> > Berkeley's Three Dialogues.
>
> ... which I couldn't care less about.
>
> --
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstuck...@attglobal.net
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

If you don't wish to continue this line of discussion, then we can
just end it without being petty.  /thread

Nilone wrote:
>>
>>> --
>>> Explain yourself in any manner of way.  Disregard the little slips in
>>> discourse.  Retract or reinforce anything you have offered, as best
>>> serve your purpose.  Hear and examine everything in fairness, and if
>>> you can find any flaw in any of your former concessions, or can think
>>> of any subterfuge, any new distinction, colour, or comment whatsoever,
>>> then produce it.  I am not for imposing any sense on your words: you
>>> are at liberty to explain them as you please. Only, I beseech you,
>>> make me understand something by them.
>>> Paraphrased from the dialogue between Hylas and Philonous in
>>> Berkeley's Three Dialogues.
>> ... which I couldn't care less about.
>>
> 
> If you don't wish to continue this line of discussion, then we can
> just end it without being petty.  /thread

Nothing petty about it, and I didn't say I wouldn't continue.  I just 
have zero interest in anything not relating to the subject at hand.

But as long as you're going to keep bringing up off-topic items, no, I'm 
not interested.

I suggest you get rid of the academics and learn what the real world is 
like.  It is much different than you think.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Jerry Stuckle wrote:
> Note #4.  An array is not a single value in the application domain.

As a matter of interest, Chris J. Date has argued that this isn't 
accurate and the idea that 'atomicity' can be defined is actually 
arbitrary. The string-is-actually-an-array-of-chars already has been 
bought up but there's also other data type that's not quite atomic: 
date. We store dates are well, dates yet it composes of several parts, 
day, month and year and possibly even time which in turns consists of 
more parts. Porting dates between different SQL databases usually are a 
big headache in its own right.

Chris J. Date then went on to assert that contrary to the popular view, 
it is not invalid in relation theory to have an attribute of a relation 
consist of a data type which itself is a relation. In other words, we 
can have a relation-valued attribute for a relation, and the type system 
for a "true" relational system ought to be allowed to be arbitrarily 
complex, but this is artifically limited by SQL databases which uses a 
set of data types but does not require any further definition of those 
data types.

Anyway, I only wanted to point out that the subject certainly isn't pat 
as one would think.

Banana wrote:
> Jerry Stuckle wrote:
>> Note #4.  An array is not a single value in the application domain.
> 
> As a matter of interest, Chris J. Date has argued that this isn't 
> accurate and the idea that 'atomicity' can be defined is actually 
> arbitrary. The string-is-actually-an-array-of-chars already has been 
> bought up but there's also other data type that's not quite atomic: 
> date. We store dates are well, dates yet it composes of several parts, 
> day, month and year and possibly even time which in turns consists of 
> more parts. Porting dates between different SQL databases usually are a 
> big headache in its own right.
> 
> Chris J. Date then went on to assert that contrary to the popular view, 
> it is not invalid in relation theory to have an attribute of a relation 
> consist of a data type which itself is a relation. In other words, we 
> can have a relation-valued attribute for a relation, and the type system 
> for a "true" relational system ought to be allowed to be arbitrarily 
> complex, but this is artifically limited by SQL databases which uses a 
> set of data types but does not require any further definition of those 
> data types.
> 
> Anyway, I only wanted to point out that the subject certainly isn't pat 
> as one would think.

I'm really not interested in academic arguments from people who have 
spent little, if any, time actually programming.  While Chris J. Date is 
a prolific author and has interesting theories, he has little real-world 
experience.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Apr 2, 2:37=A0pm, Banana <Ban...@Republic.com> wrote:
> Jerry Stuckle wrote:
> > Note #4. =A0An array is not a single value in the application domain.
>
> As a matter of interest, Chris J. Date has argued that this isn't
> accurate and the idea that 'atomicity' can be defined is actually
> arbitrary. The string-is-actually-an-array-of-chars already has been
> bought up but there's also other data type that's not quite atomic:
> date. We store dates are well, dates yet it composes of several parts,
> day, month and year and possibly even time which in turns consists of
> more parts. Porting dates between different SQL databases usually are a
> big headache in its own right.
>
> Chris J. Date then went on to assert that contrary to the popular view,
> it is not invalid in relation theory to have an attribute of a relation
> consist of a data type which itself is a relation. In other words, we
> can have a relation-valued attribute for a relation, and the type system
> for a "true" relational system ought to be allowed to be arbitrarily
> complex, but this is artifically limited by SQL databases which uses a
> set of data types but does not require any further definition of those
> data types.
>
> Anyway, I only wanted to point out that the subject certainly isn't pat
> as one would think.

Good points.  Date has certainly influenced much of my thinking about
databases, and I've recently read papers by William Cook and Bart
Jacobs which expanded my thoughts on abstraction.  Now I'm reading
Operating System Concepts by Silberschatz, Galvin and Gagne.  The
intersection of the three makes a fertile ground for speculation!

Nilone wrote:
> On Apr 2, 2:37 pm, Banana <Ban...@Republic.com> wrote:
>> Jerry Stuckle wrote:
>>> Note #4.  An array is not a single value in the application domain.
>> As a matter of interest, Chris J. Date has argued that this isn't
>> accurate and the idea that 'atomicity' can be defined is actually
>> arbitrary. The string-is-actually-an-array-of-chars already has been
>> bought up but there's also other data type that's not quite atomic:
>> date. We store dates are well, dates yet it composes of several parts,
>> day, month and year and possibly even time which in turns consists of
>> more parts. Porting dates between different SQL databases usually are a
>> big headache in its own right.
>>
>> Chris J. Date then went on to assert that contrary to the popular view,
>> it is not invalid in relation theory to have an attribute of a relation
>> consist of a data type which itself is a relation. In other words, we
>> can have a relation-valued attribute for a relation, and the type system
>> for a "true" relational system ought to be allowed to be arbitrarily
>> complex, but this is artifically limited by SQL databases which uses a
>> set of data types but does not require any further definition of those
>> data types.
>>
>> Anyway, I only wanted to point out that the subject certainly isn't pat
>> as one would think.
> 
> Good points.  Date has certainly influenced much of my thinking about
> databases, and I've recently read papers by William Cook and Bart
> Jacobs which expanded my thoughts on abstraction.  Now I'm reading
> Operating System Concepts by Silberschatz, Galvin and Gagne.  The
> intersection of the three makes a fertile ground for speculation!

All of which make for great academic theory - but are of limited use in 
the real world.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Apr 2, 3:58=A0pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> Nilone wrote:
>
> > Good points. =A0Date has certainly influenced much of my thinking about
> > databases, and I've recently read papers by William Cook and Bart
> > Jacobs which expanded my thoughts on abstraction. =A0Now I'm reading
> > Operating System Concepts by Silberschatz, Galvin and Gagne. =A0The
> > intersection of the three makes a fertile ground for speculation!
>
> All of which make for great academic theory - but are of limited use in
> the real world.

I realize that you are not interested in this topic.  Why do you
continue to read and respond to this thread if you don't want to?

I give thanks to the work of academics like Turing, Von Neumann, Codd,
Nygaard and Kay (and many others) for creating the abstractions I make
a living from.

In article <hp4t6o$aek$1@news.eternal-september.org>, Jerry Stuckle <jstucklex@attglobal.net> wrote:
>Nilone wrote:
>> On Apr 2, 2:37 pm, Banana <Ban...@Republic.com> wrote:
>>> Jerry Stuckle wrote:
>>>> Note #4.  An array is not a single value in the application domain.
>>> As a matter of interest, Chris J. Date has argued that this isn't
>>> accurate and the idea that 'atomicity' can be defined is actually
>>> arbitrary. The string-is-actually-an-array-of-chars already has been
>>> bought up but there's also other data type that's not quite atomic:
>>> date. We store dates are well, dates yet it composes of several parts,
>>> day, month and year and possibly even time which in turns consists of
>>> more parts. Porting dates between different SQL databases usually are a
>>> big headache in its own right.
>>>
>>> Chris J. Date then went on to assert that contrary to the popular view,
>>> it is not invalid in relation theory to have an attribute of a relation
>>> consist of a data type which itself is a relation. In other words, we
>>> can have a relation-valued attribute for a relation, and the type system
>>> for a "true" relational system ought to be allowed to be arbitrarily
>>> complex, but this is artifically limited by SQL databases which uses a
>>> set of data types but does not require any further definition of those
>>> data types.
>>>
>>> Anyway, I only wanted to point out that the subject certainly isn't pat
>>> as one would think.
>> 
>> Good points.  Date has certainly influenced much of my thinking about
>> databases, and I've recently read papers by William Cook and Bart
>> Jacobs which expanded my thoughts on abstraction.  Now I'm reading
>> Operating System Concepts by Silberschatz, Galvin and Gagne.  The
>> intersection of the three makes a fertile ground for speculation!
>
>All of which make for great academic theory - but are of limited use in 
>the real world.
>
Indeed, it's worth noting that manure *also* makes "fertile ground".

Nilone:

>On Apr 2, 3:58�pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Nilone wrote:
>>
>> > Good points. �Date has certainly influenced much of my thinking
>>about  > databases, and I've recently read papers by William Cook
>>and Bart  > Jacobs which expanded my thoughts on abstraction. �Now
>>I'm reading  > Operating System Concepts by Silberschatz, Galvin
>>and Gagne. �The  > intersection of the three makes a fertile ground
>>for speculation!
>>
>> All of which make for great academic theory - but are of limited
>>use in  the real world.
>
>I realize that you are not interested in this topic.  Why do you
>continue to read and respond to this thread if you don't want to?


Oh, too bad. That's not the reply I had expected from someone at a
decent level of education. Now, you invite him to explain why he does,
which is probably not really what you are interested in. (But Jerry
will now have full rights to do so).

I would have thought, that you would ask Jerry for examples where the
"academic theory" and the "real world" differ significantly. Perhaps,
upon receiving examples, you should then ask him why the real world
doesn't catch up with the academic theory.

-- 
Erick

In article <81mdbmFggbU1@mid.individual.net>, "Erick T. Barkhuis" <erick.use-net@ardane.c.o.m> wrote:
>Nilone:
>
>>On Apr 2, 3:58�pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>> Nilone wrote:
>>>
>>> > Good points. �Date has certainly influenced much of my thinking
>>>about  > databases, and I've recently read papers by William Cook
>>>and Bart  > Jacobs which expanded my thoughts on abstraction. �Now
>>>I'm reading  > Operating System Concepts by Silberschatz, Galvin
>>>and Gagne. �The  > intersection of the three makes a fertile ground
>>>for speculation!
>>>
>>> All of which make for great academic theory - but are of limited
>>>use in  the real world.
>>
>>I realize that you are not interested in this topic.  Why do you
>>continue to read and respond to this thread if you don't want to?
>
>
>Oh, too bad. That's not the reply I had expected from someone at a
>decent level of education. Now, you invite him to explain why he does,
>which is probably not really what you are interested in. (But Jerry
>will now have full rights to do so).
>
>I would have thought, that you would ask Jerry for examples where the
>"academic theory" and the "real world" differ significantly. Perhaps,
>upon receiving examples, you should then ask him why the real world
>doesn't catch up with the academic theory.
>
LOL! I think you might have that backwards...

Nilone wrote:
> On Apr 2, 3:58 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Nilone wrote:
>>
>>> Good points.  Date has certainly influenced much of my thinking about
>>> databases, and I've recently read papers by William Cook and Bart
>>> Jacobs which expanded my thoughts on abstraction.  Now I'm reading
>>> Operating System Concepts by Silberschatz, Galvin and Gagne.  The
>>> intersection of the three makes a fertile ground for speculation!
>> All of which make for great academic theory - but are of limited use in
>> the real world.
> 
> I realize that you are not interested in this topic.  Why do you
> continue to read and respond to this thread if you don't want to?
> 
> I give thanks to the work of academics like Turing, Von Neumann, Codd,
> Nygaard and Kay (and many others) for creating the abstractions I make
> a living from.

That's where you are wrong.  I am very interested in the topic.  But 
interested in the real world aspects, not academic theory proposed by 
people with no experience in real-world programming.

When the academics start to understand what the real world is like, I 
will give them some credit.  But most of what you have quoted is pure 
manure in real-world programming.

And this is a programmers' newsgroup.  If you want to argue academics, 
you are in the wrong place.

And I make quite a good living without the junk they espouse, thank you. 
  The difference is, I actually help people and companies, not fill 
their minds full of manure.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Apr 2, 4:30=A0pm, "Erick T. Barkhuis" <erick.use-...@ardane.c.o.m>
wrote:
> Nilone:
>
> >On Apr 2, 3:58=A0pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> >> Nilone wrote:
>
> >> > Good points. =A0Date has certainly influenced much of my thinking
> >>about =A0> databases, and I've recently read papers by William Cook
> >>and Bart =A0> Jacobs which expanded my thoughts on abstraction. =A0Now
> >>I'm reading =A0> Operating System Concepts by Silberschatz, Galvin
> >>and Gagne. =A0The =A0> intersection of the three makes a fertile ground
> >>for speculation!
>
> >> All of which make for great academic theory - but are of limited
> >>use in =A0the real world.
>
> >I realize that you are not interested in this topic. =A0Why do you
> >continue to read and respond to this thread if you don't want to?
>
> Oh, too bad. That's not the reply I had expected from someone at a
> decent level of education. Now, you invite him to explain why he does,
> which is probably not really what you are interested in. (But Jerry
> will now have full rights to do so).
>
> I would have thought, that you would ask Jerry for examples where the
> "academic theory" and the "real world" differ significantly. Perhaps,
> upon receiving examples, you should then ask him why the real world
> doesn't catch up with the academic theory.
>
> --
> Erick

I wish I had thought of that!  You raise good points, and although I'm
skeptical, perhaps Jerry will respond to argue his.  It would be
foolish to disregard the insights of practical experience.

Also, thank you for the compliment.

On Apr 2, 7:43=A0pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> Nilone wrote:
> > On Apr 2, 3:58 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> >> Nilone wrote:
>
> >>> Good points. =A0Date has certainly influenced much of my thinking abo=
ut
> >>> databases, and I've recently read papers by William Cook and Bart
> >>> Jacobs which expanded my thoughts on abstraction. =A0Now I'm reading
> >>> Operating System Concepts by Silberschatz, Galvin and Gagne. =A0The
> >>> intersection of the three makes a fertile ground for speculation!
> >> All of which make for great academic theory - but are of limited use i=
n
> >> the real world.
>
> > I realize that you are not interested in this topic. =A0Why do you
> > continue to read and respond to this thread if you don't want to?
>
> > I give thanks to the work of academics like Turing, Von Neumann, Codd,
> > Nygaard and Kay (and many others) for creating the abstractions I make
> > a living from.
>
> That's where you are wrong. =A0I am very interested in the topic. =A0But
> interested in the real world aspects, not academic theory proposed by
> people with no experience in real-world programming.
>
> When the academics start to understand what the real world is like, I
> will give them some credit. =A0But most of what you have quoted is pure
> manure in real-world programming.

I started on this path almost a decade ago.  I got burned by the
object-relational mismatch, trying to map my entity classes onto
tables.  Stupid, of course, and I nearly killed my project.  Since
then, I've been studying to understand the cause of the problem, and
it brought me to my current point of view.  When I create a system, I
need to know how to decompose it effectively and efficiently, and
which data structures to use in every situation.  I need to know how
to use existing data structures to build new ones, since I'm tired of
rewriting the same old logic.  I need to achieve more in time spent
analyzing and designing, and I definitely need to reduce maintenance
time.  I refactor large pieces of code for small improvements and
struggle with complex tools for little gain.  This IS the real world,
not just an academic exercise.

>
> And this is a programmers' newsgroup. =A0If you want to argue academics,
> you are in the wrong place.

I don't want to argue.  I want to learn and improve.  If you have
insight to offer, I will take it gladly.  If not, I will get it
elsewhere.  If any of what I've read can be useful to other people,
I'll gladly share.

>
> And I make quite a good living without the junk they espouse, thank you.
> =A0 The difference is, I actually help people and companies, not fill
> their minds full of manure.

I'm sure you do and I'm a little envious of the security you seem to
have in your life.  In my own way, I'm striving to do the same.

Nilone wrote:
> On Apr 2, 7:43 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Nilone wrote:
>>> On Apr 2, 3:58 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>> Nilone wrote:
>>>>> Good points.  Date has certainly influenced much of my thinking about
>>>>> databases, and I've recently read papers by William Cook and Bart
>>>>> Jacobs which expanded my thoughts on abstraction.  Now I'm reading
>>>>> Operating System Concepts by Silberschatz, Galvin and Gagne.  The
>>>>> intersection of the three makes a fertile ground for speculation!
>>>> All of which make for great academic theory - but are of limited use in
>>>> the real world.
>>> I realize that you are not interested in this topic.  Why do you
>>> continue to read and respond to this thread if you don't want to?
>>> I give thanks to the work of academics like Turing, Von Neumann, Codd,
>>> Nygaard and Kay (and many others) for creating the abstractions I make
>>> a living from.
>> That's where you are wrong.  I am very interested in the topic.  But
>> interested in the real world aspects, not academic theory proposed by
>> people with no experience in real-world programming.
>>
>> When the academics start to understand what the real world is like, I
>> will give them some credit.  But most of what you have quoted is pure
>> manure in real-world programming.
> 
> I started on this path almost a decade ago.  I got burned by the
> object-relational mismatch, trying to map my entity classes onto
> tables.  Stupid, of course, and I nearly killed my project.  Since
> then, I've been studying to understand the cause of the problem, and
> it brought me to my current point of view.  When I create a system, I
> need to know how to decompose it effectively and efficiently, and
> which data structures to use in every situation.  I need to know how
> to use existing data structures to build new ones, since I'm tired of
> rewriting the same old logic.  I need to achieve more in time spent
> analyzing and designing, and I definitely need to reduce maintenance
> time.  I refactor large pieces of code for small improvements and
> struggle with complex tools for little gain.  This IS the real world,
> not just an academic exercise.
> 

Then I apologize.  Your quoting of all the theory reminds me of 
professors I had back in college.  Of course, that was 40 years ago and 
things have changed - but professors haven't.  I learned languages in 
college.  I learned to program in the real world.

You have a problem fitting an OO design into a relational database 
because you are trying to fit a square peg in a round hole.  Most SQL 
databases are not OO databases, although the number of OO databases is 
available is growing.

Nevertheless, it is something we need to do.  But it's not necessarily 
easy, and what you're asking comes only with experience, not academic 
theory.  It comes with proper design and planning - not only for what is 
necessary now, but could realistically be required in the future.  You 
can't plan for every contingency - but experience helps to know what you 
should plan for.

Things like rewriting can also be minimized by proper design and 
separation of the business logic from the storage and presentation 
logics.  And sometimes it needs to be broken down even more.

I'm not trying to be condescending, but with less than 10 years of 
experience, you are still relatively new - especially if you've been 
doing this on your own.  OTOH, if you had been working in a corporate 
environment on projects with other good programmers, you could have 
picked up a lot of experience from them and been able to progress much 
faster.

>> And this is a programmers' newsgroup.  If you want to argue academics,
>> you are in the wrong place.
> 
> I don't want to argue.  I want to learn and improve.  If you have
> insight to offer, I will take it gladly.  If not, I will get it
> elsewhere.  If any of what I've read can be useful to other people,
> I'll gladly share.
>

Again - it comes from experience.  There is no substitute.

>> And I make quite a good living without the junk they espouse, thank you.
>>   The difference is, I actually help people and companies, not fill
>> their minds full of manure.
> 
> I'm sure you do and I'm a little envious of the security you seem to
> have in your life.  In my own way, I'm striving to do the same.

Then forget about the academics and look at real world examples.  Don't 
bother with searching the internet - the vast majority of the samples 
out there are crap.  Rather, get some good books on *practical* design. 
  See how the experts do it.

And remember - there never is a "right way" to do something in 
programming.  There are always many ways to do anything.  Some are 
better than others.  Design is all about finding the way which fits your 
needs best.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Apr 2, 10:56=A0pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>
> Then I apologize. =A0Your quoting of all the theory reminds me of
> professors I had back in college. =A0Of course, that was 40 years ago and
> things have changed - but professors haven't. =A0I learned languages in
> college. =A0I learned to program in the real world.

No apologies needed.  I realize that my theory dump was obtuse.

>
> You have a problem fitting an OO design into a relational database
> because you are trying to fit a square peg in a round hole. =A0Most SQL
> databases are not OO databases, although the number of OO databases is
> available is growing.
>
> Nevertheless, it is something we need to do. =A0But it's not necessarily
> easy, and what you're asking comes only with experience, not academic
> theory. =A0It comes with proper design and planning - not only for what i=
s
> necessary now, but could realistically be required in the future. =A0You
> can't plan for every contingency - but experience helps to know what you
> should plan for.
>
> Things like rewriting can also be minimized by proper design and
> separation of the business logic from the storage and presentation
> logics. =A0And sometimes it needs to be broken down even more.
>
> I'm not trying to be condescending, but with less than 10 years of
> experience, you are still relatively new - especially if you've been
> doing this on your own. =A0OTOH, if you had been working in a corporate
> environment on projects with other good programmers, you could have
> picked up a lot of experience from them and been able to progress much
> faster.
>
> >> And this is a programmers' newsgroup. =A0If you want to argue academic=
s,
> >> you are in the wrong place.
>
> > I don't want to argue. =A0I want to learn and improve. =A0If you have
> > insight to offer, I will take it gladly. =A0If not, I will get it
> > elsewhere. =A0If any of what I've read can be useful to other people,
> > I'll gladly share.
>
> Again - it comes from experience. =A0There is no substitute.
>
> >> And I make quite a good living without the junk they espouse, thank yo=
u.
> >> =A0 The difference is, I actually help people and companies, not fill
> >> their minds full of manure.
>
> > I'm sure you do and I'm a little envious of the security you seem to
> > have in your life. =A0In my own way, I'm striving to do the same.
>
> Then forget about the academics and look at real world examples. =A0Don't
> bother with searching the internet - the vast majority of the samples
> out there are crap. =A0Rather, get some good books on *practical* design.
> =A0 See how the experts do it.
>
> And remember - there never is a "right way" to do something in
> programming. =A0There are always many ways to do anything. =A0Some are
> better than others. =A0Design is all about finding the way which fits you=
r
> needs best.

You argue for experience rather than theory, but in my experience, the
lack of theory left me frustrated and without direction, wasting time
implementing techniques that didn't work.  I understand by visualizing
and manipulating structures in my head.  Studying theoretical models
provides me with the tools to do that, which allows me to reason about
different scenarios.

I've been studying OOP and databases for 10 years, but I've been
programming for twice as long.  I may not have the most experience
around here, but I'm certainly not a noob.

It may be that I learn better from reading and rereading, while you
are more perceptive than I am in practical situations.  I can also
understand your dislike of theory since I have a similar dislike for
mathematical and formal notation.  However, the only way I know of to
gain understanding in a conversation is to reason with a person.  If I
make an assertion and you disagree, how can I learn unless you provide
the reason for that disagreement?  I consider it a win to be proven
wrong, because that shows me exactly what I need to learn next.

Theory, contradiction and discussing hypotheticals isn't every
person's path to success, so if you think our approaches to finding
solutions are just too different, then let us just part in peace.  I
realize that my method of learning might seem like negative criticism
to others, so if you need me to avoid responding to your posts, I can
do that, if you'll then do the same for me.  However, if you wish to
reason with me, I'll be happy to do so.  Please feel free to suggest
any other modes of interaction if you wish.

Nilone wrote:
> On Apr 2, 10:56 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Then I apologize.  Your quoting of all the theory reminds me of
>> professors I had back in college.  Of course, that was 40 years ago and
>> things have changed - but professors haven't.  I learned languages in
>> college.  I learned to program in the real world.
> 
> No apologies needed.  I realize that my theory dump was obtuse.
> 
>> You have a problem fitting an OO design into a relational database
>> because you are trying to fit a square peg in a round hole.  Most SQL
>> databases are not OO databases, although the number of OO databases is
>> available is growing.
>>
>> Nevertheless, it is something we need to do.  But it's not necessarily
>> easy, and what you're asking comes only with experience, not academic
>> theory.  It comes with proper design and planning - not only for what is
>> necessary now, but could realistically be required in the future.  You
>> can't plan for every contingency - but experience helps to know what you
>> should plan for.
>>
>> Things like rewriting can also be minimized by proper design and
>> separation of the business logic from the storage and presentation
>> logics.  And sometimes it needs to be broken down even more.
>>
>> I'm not trying to be condescending, but with less than 10 years of
>> experience, you are still relatively new - especially if you've been
>> doing this on your own.  OTOH, if you had been working in a corporate
>> environment on projects with other good programmers, you could have
>> picked up a lot of experience from them and been able to progress much
>> faster.
>>
>>>> And this is a programmers' newsgroup.  If you want to argue academics,
>>>> you are in the wrong place.
>>> I don't want to argue.  I want to learn and improve.  If you have
>>> insight to offer, I will take it gladly.  If not, I will get it
>>> elsewhere.  If any of what I've read can be useful to other people,
>>> I'll gladly share.
>> Again - it comes from experience.  There is no substitute.
>>
>>>> And I make quite a good living without the junk they espouse, thank you.
>>>>   The difference is, I actually help people and companies, not fill
>>>> their minds full of manure.
>>> I'm sure you do and I'm a little envious of the security you seem to
>>> have in your life.  In my own way, I'm striving to do the same.
>> Then forget about the academics and look at real world examples.  Don't
>> bother with searching the internet - the vast majority of the samples
>> out there are crap.  Rather, get some good books on *practical* design.
>>   See how the experts do it.
>>
>> And remember - there never is a "right way" to do something in
>> programming.  There are always many ways to do anything.  Some are
>> better than others.  Design is all about finding the way which fits your
>> needs best.
> 
> You argue for experience rather than theory, but in my experience, the
> lack of theory left me frustrated and without direction, wasting time
> implementing techniques that didn't work.  I understand by visualizing
> and manipulating structures in my head.  Studying theoretical models
> provides me with the tools to do that, which allows me to reason about
> different scenarios.
> 
> I've been studying OOP and databases for 10 years, but I've been
> programming for twice as long.  I may not have the most experience
> around here, but I'm certainly not a noob.
>

I didn't mean to indicate you are a noob.  But if you've been learning 
on your own for 10+ years, you've done it the hard way.  It's like 
trying to become conversant in a foreign language.  Sure, you can do it 
from tapes and books, but you will never be fluent that way.  It's much 
easier if you have people who use it as their native language to help 
you, and the only way to become really fluent in the language.

> It may be that I learn better from reading and rereading, while you
> are more perceptive than I am in practical situations.  I can also
> understand your dislike of theory since I have a similar dislike for
> mathematical and formal notation.  However, the only way I know of to
> gain understanding in a conversation is to reason with a person.  If I
> make an assertion and you disagree, how can I learn unless you provide
> the reason for that disagreement?  I consider it a win to be proven
> wrong, because that shows me exactly what I need to learn next.
> 
> Theory, contradiction and discussing hypotheticals isn't every
> person's path to success, so if you think our approaches to finding
> solutions are just too different, then let us just part in peace.  I
> realize that my method of learning might seem like negative criticism
> to others, so if you need me to avoid responding to your posts, I can
> do that, if you'll then do the same for me.  However, if you wish to
> reason with me, I'll be happy to do so.  Please feel free to suggest
> any other modes of interaction if you wish.

Theory has its place.  However, the theories you have quoted generally 
have little application in the real world.  It's not criticism of you; 
rather it is recognition that academia really has little relationship to 
anything outside if its own little world.

Which is why I recommended some good practical books.  Rather than just 
give you some abstract concepts, they will show you how the applications 
were designed - but more importantly, they will take you though the hows 
and whys of decisions which were made during the process.

It's easy to be a hacker all your life; there are some of those here on 
this newsgroup.  It's much harder to become a good programmer.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Nilone wrote:
>
> 
> Theory, contradiction and discussing hypotheticals isn't every
> person's path to success, so if you think our approaches to finding
> solutions are just too different, then let us just part in peace.  I
> realize that my method of learning might seem like negative criticism
> to others, so if you need me to avoid responding to your posts, I can
> do that, if you'll then do the same for me.  However, if you wish to
> reason with me, I'll be happy to do so.  Please feel free to suggest
> any other modes of interaction if you wish.

1% of people need to go back to basics, consult deep theory, and come up 
with a way of working, which will be completely understood by 5%, copied 
shamelessly by 15%, taught as the One True Way By Jerry Stuckle (Ex 
Cathedra), and completely ignored by the vast heaving mass of humanity 
as being suspiciously smart arse.

That is, sadly, the way of the world.

Most practical development is pure plagiarism of one sort or another.

Don't confuse the 15% who copy, with the 5% who understand, or the 1% 
who are capable of original analysis.

And don't confuse the vast heaving mass, or Jerry, at all.  Its cruelty 
to lesser beings, and you should know better.

The Natural Philosopher wrote:
> Nilone wrote:
>>
>>
>> Theory, contradiction and discussing hypotheticals isn't every
>> person's path to success, so if you think our approaches to finding
>> solutions are just too different, then let us just part in peace.  I
>> realize that my method of learning might seem like negative criticism
>> to others, so if you need me to avoid responding to your posts, I can
>> do that, if you'll then do the same for me.  However, if you wish to
>> reason with me, I'll be happy to do so.  Please feel free to suggest
>> any other modes of interaction if you wish.
> 
> 1% of people need to go back to basics, consult deep theory, and come up 
> with a way of working, which will be completely understood by 5%, copied 
> shamelessly by 15%, taught as the One True Way By Jerry Stuckle (Ex 
> Cathedra), and completely ignored by the vast heaving mass of humanity 
> as being suspiciously smart arse.
> 
> That is, sadly, the way of the world.
> 
> Most practical development is pure plagiarism of one sort or another.
> 
> Don't confuse the 15% who copy, with the 5% who understand, or the 1% 
> who are capable of original analysis.
> 
> And don't confuse the vast heaving mass, or Jerry, at all.  Its cruelty 
> to lesser beings, and you should know better.

Speaking of hackers who know absolutely nothing... I was wondering when 
the King of the Dill would show up.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Apr 3, 3:21=A0am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>
> Theory has its place. =A0However, the theories you have quoted generally
> have little application in the real world. =A0It's not criticism of you;
> rather it is recognition that academia really has little relationship to
> anything outside if its own little world.

To me, those theories seem directly applicable to the problem.  My
understanding of the relational model directly affects how I design my
tables and write my queries.  Understanding the difference between
algebraic and coalgebraic structures resolved issues I had with
knowing when and how to use classes and inheritance, and it explained
why classes don't map to tables.

>
> Which is why I recommended some good practical books. =A0Rather than just
> give you some abstract concepts, they will show you how the applications
> were designed - but more importantly, they will take you though the hows
> and whys of decisions which were made during the process.

I've tried that in the past, more than once.  Other solutions never
correspond exactly to mine, and when I try to adapt them, it breaks
the relationships that make them work.

>
> It's easy to be a hacker all your life; there are some of those here on
> this newsgroup. =A0It's much harder to become a good programmer.

Agreed.

On Apr 3, 3:28=A0am, The Natural Philosopher <t...@invalid.invalid>
wrote:
> Nilone wrote:
>
> > Theory, contradiction and discussing hypotheticals isn't every
> > person's path to success, so if you think our approaches to finding
> > solutions are just too different, then let us just part in peace. =A0I
> > realize that my method of learning might seem like negative criticism
> > to others, so if you need me to avoid responding to your posts, I can
> > do that, if you'll then do the same for me. =A0However, if you wish to
> > reason with me, I'll be happy to do so. =A0Please feel free to suggest
> > any other modes of interaction if you wish.
>
> 1% of people need to go back to basics, consult deep theory, and come up
> with a way of working, which will be completely understood by 5%, copied
> shamelessly by 15%, taught as the One True Way By Jerry Stuckle (Ex
> Cathedra), and completely ignored by the vast heaving mass of humanity
> as being suspiciously smart arse.
>
> That is, sadly, the way of the world.
>
> Most practical development is pure plagiarism of one sort or another.
>
> Don't confuse the 15% who copy, with the 5% who understand, or the 1%
> who are capable of original analysis.
>
> And don't confuse the vast heaving mass, or Jerry, at all. =A0Its cruelty
> to lesser beings, and you should know better.

It strikes me that Jerry is trying to help, in a coalgebraic way, by
showing me how to map to the behaviour of a good programmer.  However,
I'm an algebraic kind of programmer, and I really need to represent my
ideas directly.  I hope my conversation with him will provide insight
on the interaction of the two concepts.

Nilone wrote:
> On Apr 3, 3:21 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Theory has its place.  However, the theories you have quoted generally
>> have little application in the real world.  It's not criticism of you;
>> rather it is recognition that academia really has little relationship to
>> anything outside if its own little world.
> 
> To me, those theories seem directly applicable to the problem.  My
> understanding of the relational model directly affects how I design my
> tables and write my queries.  Understanding the difference between
> algebraic and coalgebraic structures resolved issues I had with
> knowing when and how to use classes and inheritance, and it explained
> why classes don't map to tables.
>

I'm glad you think they are applicable.  But they really have no place 
in practical programming.  Understanding the concept of objects and 
inheritance does help - just like understanding the concept of 
functional programming does.  However, there is nothing algebraic or 
coalgebraic about it.

And as I said before - mapping classes to a non-OO database is fitting a 
square peg into a round hole.  No matter how you twist and turn, it 
never fits quite right.  It is, however, something we have to make work.

>> Which is why I recommended some good practical books.  Rather than just
>> give you some abstract concepts, they will show you how the applications
>> were designed - but more importantly, they will take you though the hows
>> and whys of decisions which were made during the process.
> 
> I've tried that in the past, more than once.  Other solutions never
> correspond exactly to mine, and when I try to adapt them, it breaks
> the relationships that make them work.
> 

As I said before - there are many ways of doing the same thing.   But 
I'm not saying you should try to adapt other solutions to your needs - 
especially when they don't directly correspond to what you need. 
Rather, you need to *understand* the design, the choices which were made 
during the design, and most importantly, *why* those choices were made.

You can study the theory of how to drive a car all you want; only by 
getting behind the wheel will you become a good driver.  And it helps if 
you have a good teacher.

>> It's easy to be a hacker all your life; there are some of those here on
>> this newsgroup.  It's much harder to become a good programmer.
> 
> Agreed.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Apr 3, 11:09=A0am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> Nilone wrote:
> > On Apr 3, 3:21 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> >> Theory has its place. =A0However, the theories you have quoted general=
ly
> >> have little application in the real world. =A0It's not criticism of yo=
u;
> >> rather it is recognition that academia really has little relationship =
to
> >> anything outside if its own little world.
>
> > To me, those theories seem directly applicable to the problem. =A0My
> > understanding of the relational model directly affects how I design my
> > tables and write my queries. =A0Understanding the difference between
> > algebraic and coalgebraic structures resolved issues I had with
> > knowing when and how to use classes and inheritance, and it explained
> > why classes don't map to tables.
>
> I'm glad you think they are applicable. =A0But they really have no place
> in practical programming. =A0Understanding the concept of objects and
> inheritance does help - just like understanding the concept of
> functional programming does. =A0However, there is nothing algebraic or
> coalgebraic about it.
>
> And as I said before - mapping classes to a non-OO database is fitting a
> square peg into a round hole. =A0No matter how you twist and turn, it
> never fits quite right. =A0It is, however, something we have to make work=
..
>
> >> Which is why I recommended some good practical books. =A0Rather than j=
ust
> >> give you some abstract concepts, they will show you how the applicatio=
ns
> >> were designed - but more importantly, they will take you though the ho=
ws
> >> and whys of decisions which were made during the process.
>
> > I've tried that in the past, more than once. =A0Other solutions never
> > correspond exactly to mine, and when I try to adapt them, it breaks
> > the relationships that make them work.
>
> As I said before - there are many ways of doing the same thing. =A0 But
> I'm not saying you should try to adapt other solutions to your needs -
> especially when they don't directly correspond to what you need.
> Rather, you need to *understand* the design, the choices which were made
> during the design, and most importantly, *why* those choices were made.
>
> You can study the theory of how to drive a car all you want; only by
> getting behind the wheel will you become a good driver. =A0And it helps i=
f
> you have a good teacher.

Sigh.  Instead of asking why I hold my views, you contradict me by
repeating what you've said before.  I appreciate your attempt to help,
but I think differently than you do, and you're not providing what I
need to understand.  Let's end this thread.

Nilone wrote:
> On Apr 3, 3:28 am, The Natural Philosopher <t...@invalid.invalid>
> wrote:
>> Nilone wrote:
>>
>>> Theory, contradiction and discussing hypotheticals isn't every
>>> person's path to success, so if you think our approaches to finding
>>> solutions are just too different, then let us just part in peace.  I
>>> realize that my method of learning might seem like negative criticism
>>> to others, so if you need me to avoid responding to your posts, I can
>>> do that, if you'll then do the same for me.  However, if you wish to
>>> reason with me, I'll be happy to do so.  Please feel free to suggest
>>> any other modes of interaction if you wish.
>> 1% of people need to go back to basics, consult deep theory, and come up
>> with a way of working, which will be completely understood by 5%, copied
>> shamelessly by 15%, taught as the One True Way By Jerry Stuckle (Ex
>> Cathedra), and completely ignored by the vast heaving mass of humanity
>> as being suspiciously smart arse.
>>
>> That is, sadly, the way of the world.
>>
>> Most practical development is pure plagiarism of one sort or another.
>>
>> Don't confuse the 15% who copy, with the 5% who understand, or the 1%
>> who are capable of original analysis.
>>
>> And don't confuse the vast heaving mass, or Jerry, at all.  Its cruelty
>> to lesser beings, and you should know better.
> 
> It strikes me that Jerry is trying to help, in a coalgebraic way, by
> showing me how to map to the behaviour of a good programmer. 

No, what he *considers* to be a 'good programmer'  i.e. someone who has 
learnt by rote what he was taught by rote, and now attempts to teach by 
rote.

There is a subtle but important distinction.


> However,
> I'm an algebraic kind of programmer, and I really need to represent my
> ideas directly.  I hope my conversation with him will provide insight
> on the interaction of the two concepts.

I don't understand what you mean there, but I have also found that some 
kinds of problems of data representation map extremely badly onto the 
relational databases model as it currently exists in MySQL.  In 
particular recursive hierarchies and trees and so on. And networks as such.

In such cases the solution is always a 'hack' and being a good 
programmer, to me, means considering the situation and finding the least 
offensive and most practical hack.

Or ditching relational databases and designing new data structures.

algebraic analysis and hacking are two ends of a spectrum of tools 
available. In practical terms its not always possible to say which 
represents the most effective route to go down. Turing etc.

Cf. once upon a time when I was designing a VHF receiver, we had a noise 
problem. I knew it was in the VHF part, but was too busy to tackle it as 
I had other more urgent problems. The Management brought in a consultant 
who said ;'wher'es the problem? 'In the third party tuner head' I 
replied' How do you know?' 'I cant remember, but it is'

HE went away and spent two weeks analysing my circuitry and found 
nothing wrong..at which point I remembred 'because if you remove the 
head and inject  a clean signal into my circuitry, the noise vanishes' 
I said..

Sometimes 30 seconds with a coaxial cable is a lot quicker than two 
weeks of noise calculations..

Conversely, in another life we were working on the design of a 
battlefield laser rangefinder. Try as we might, we could not tweak it to 
better than 2km range against a real target in clear air. Useless in 
battlefield conditions.

A consultant arrived, and asked two questions 'what power is the laser' 
' what is the noise figure of the photodetector' and after about two 
minutes with a slide rule said 'that should represent a theoretical 
maximum effective range of about..1.5km'.

Theory is mostly good it seems at telling you what is possible and what 
is not, but sometimes it isn't much help in achieving it. Especially if 
your problem isn't well represented by the theory.

On Apr 3, 12:24=A0pm, The Natural Philosopher <t...@invalid.invalid>
wrote:
>
> No, what he *considers* to be a 'good programmer' =A0i.e. someone who has
> learnt by rote what he was taught by rote, and now attempts to teach by
> rote.
>
> There is a subtle but important distinction.

Like a recursively defined type, it seems to me he views a good
programmer as one who does what other good programmers do.  Trying to
execute the loop just brings you back to where you started.  So we
need a fixed point.  I would have to find a good programmer who Jerry
recognizes as a good programmer.  Then, if I could show that what I'm
doing is similar to what he/she did, that would qualify me as one
too.  To me, that just seems like a lot of effort to gain approval.

>
> > However,
> > I'm an algebraic kind of programmer, and I really need to represent my
> > ideas directly. =A0I hope my conversation with him will provide insight
> > on the interaction of the two concepts.
>
> I don't understand what you mean there, but I have also found that some
> kinds of problems of data representation map extremely badly onto the
> relational databases model as it currently exists in MySQL. =A0In
> particular recursive hierarchies and trees and so on. And networks as suc=
h.

Right.  A lot of that would be alleviated by support for array-valued
attributes, tuple-valued attributes, relation-valued attributes, and
so on.  I'd like to have function-valued attributes, too.
Unfortunately, based on history, all those features would be used
incorrectly and be seen as detrimental.

>
> In such cases the solution is always a 'hack' and being a good
> programmer, to me, means considering the situation and finding the least
> offensive and most practical hack.
>
> Or ditching relational databases and designing new data structures.
>
> algebraic analysis and hacking are two ends of a spectrum of tools
> available. In practical terms its not always possible to say which
> represents the most effective route to go down. Turing etc.
>
> Cf. once upon a time when I was designing a VHF receiver, we had a noise
> problem. I knew it was in the VHF part, but was too busy to tackle it as
> I had other more urgent problems. The Management brought in a consultant
> who said ;'wher'es the problem? 'In the third party tuner head' I
> replied' How do you know?' 'I cant remember, but it is'
>
> HE went away and spent two weeks analysing my circuitry and found
> nothing wrong..at which point I remembred 'because if you remove the
> head and inject =A0a clean signal into my circuitry, the noise vanishes'
> I said..
>
> Sometimes 30 seconds with a coaxial cable is a lot quicker than two
> weeks of noise calculations..
>
> Conversely, in another life we were working on the design of a
> battlefield laser rangefinder. Try as we might, we could not tweak it to
> better than 2km range against a real target in clear air. Useless in
> battlefield conditions.
>
> A consultant arrived, and asked two questions 'what power is the laser'
> ' what is the noise figure of the photodetector' and after about two
> minutes with a slide rule said 'that should represent a theoretical
> maximum effective range of about..1.5km'.
>
> Theory is mostly good it seems at telling you what is possible and what
> is not, but sometimes it isn't much help in achieving it. Especially if
> your problem isn't well represented by the theory.

Wow, interesting fields you've worked in.  Point taken.  I would take
the former solution if I could find it or happen to think of it, but
barring that, I'm just going to work my way through theory until I
resolve the whole situation in my own mind.  If no solution is
possible, then I have to find proof that it isn't possible, or die
trying.  Giving up and living with the mismatch is simply not an
option for me.  Fortunately, my recent studies resolved a lot, so I
feel like I've got a good grip on the issue.  That illusion will
probably break soon, as it has done before, and then I'll hit the
books again.

Nilone wrote:
> On Apr 3, 11:09 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Nilone wrote:
>>> On Apr 3, 3:21 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>> Theory has its place.  However, the theories you have quoted generally
>>>> have little application in the real world.  It's not criticism of you;
>>>> rather it is recognition that academia really has little relationship to
>>>> anything outside if its own little world.
>>> To me, those theories seem directly applicable to the problem.  My
>>> understanding of the relational model directly affects how I design my
>>> tables and write my queries.  Understanding the difference between
>>> algebraic and coalgebraic structures resolved issues I had with
>>> knowing when and how to use classes and inheritance, and it explained
>>> why classes don't map to tables.
>> I'm glad you think they are applicable.  But they really have no place
>> in practical programming.  Understanding the concept of objects and
>> inheritance does help - just like understanding the concept of
>> functional programming does.  However, there is nothing algebraic or
>> coalgebraic about it.
>>
>> And as I said before - mapping classes to a non-OO database is fitting a
>> square peg into a round hole.  No matter how you twist and turn, it
>> never fits quite right.  It is, however, something we have to make work.
>>
>>>> Which is why I recommended some good practical books.  Rather than just
>>>> give you some abstract concepts, they will show you how the applications
>>>> were designed - but more importantly, they will take you though the hows
>>>> and whys of decisions which were made during the process.
>>> I've tried that in the past, more than once.  Other solutions never
>>> correspond exactly to mine, and when I try to adapt them, it breaks
>>> the relationships that make them work.
>> As I said before - there are many ways of doing the same thing.   But
>> I'm not saying you should try to adapt other solutions to your needs -
>> especially when they don't directly correspond to what you need.
>> Rather, you need to *understand* the design, the choices which were made
>> during the design, and most importantly, *why* those choices were made.
>>
>> You can study the theory of how to drive a car all you want; only by
>> getting behind the wheel will you become a good driver.  And it helps if
>> you have a good teacher.
> 
> Sigh.  Instead of asking why I hold my views, you contradict me by
> repeating what you've said before.  I appreciate your attempt to help,
> but I think differently than you do, and you're not providing what I
> need to understand.  Let's end this thread.

Sign.  Instead of trying to think differently, you keep thinking the 
same way.  That's why you're making the same mistakes time and time 
again - you keep doing what you're doing, and you'll keep getting what 
you got.

What I am trying to do is help you change your thinking.  But first you 
must be open to learning.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Nilone wrote:
> On Apr 3, 12:24 pm, The Natural Philosopher <t...@invalid.invalid>
> wrote:
>> No, what he *considers* to be a 'good programmer'  i.e. someone who has
>> learnt by rote what he was taught by rote, and now attempts to teach by
>> rote.
>>
>> There is a subtle but important distinction.
> 
> Like a recursively defined type, it seems to me he views a good
> programmer as one who does what other good programmers do.  Trying to
> execute the loop just brings you back to where you started.  So we
> need a fixed point.  I would have to find a good programmer who Jerry
> recognizes as a good programmer.  Then, if I could show that what I'm
> doing is similar to what he/she did, that would qualify me as one
> too.  To me, that just seems like a lot of effort to gain approval.
>

That is correct.  How do you think they got to be considered good 
programmers?  Because they can design and build code which is easy to 
understand, maintainable and does the job.

Poor programmers do not do the above.

And I've told you how to find good learning tools - hit the book store 
for a start.

This isn't about approval.  I personally don't care what you write.  But 
you came here looking for help, and I'm trying to provide it.  Yet you 
seem not to want help.

>>> However,
>>> I'm an algebraic kind of programmer, and I really need to represent my
>>> ideas directly.  I hope my conversation with him will provide insight
>>> on the interaction of the two concepts.
>> I don't understand what you mean there, but I have also found that some
>> kinds of problems of data representation map extremely badly onto the
>> relational databases model as it currently exists in MySQL.  In
>> particular recursive hierarchies and trees and so on. And networks as such.
> 
> Right.  A lot of that would be alleviated by support for array-valued
> attributes, tuple-valued attributes, relation-valued attributes, and
> so on.  I'd like to have function-valued attributes, too.
> Unfortunately, based on history, all those features would be used
> incorrectly and be seen as detrimental.
> 

And exactly what problems would these fix?  What even is a 
"function-valued attribute"?

>> In such cases the solution is always a 'hack' and being a good
>> programmer, to me, means considering the situation and finding the least
>> offensive and most practical hack.
>>
>> Or ditching relational databases and designing new data structures.
>>
>> algebraic analysis and hacking are two ends of a spectrum of tools
>> available. In practical terms its not always possible to say which
>> represents the most effective route to go down. Turing etc.
>>
>> Cf. once upon a time when I was designing a VHF receiver, we had a noise
>> problem. I knew it was in the VHF part, but was too busy to tackle it as
>> I had other more urgent problems. The Management brought in a consultant
>> who said ;'wher'es the problem? 'In the third party tuner head' I
>> replied' How do you know?' 'I cant remember, but it is'
>>
>> HE went away and spent two weeks analysing my circuitry and found
>> nothing wrong..at which point I remembred 'because if you remove the
>> head and inject  a clean signal into my circuitry, the noise vanishes'
>> I said..
>>
>> Sometimes 30 seconds with a coaxial cable is a lot quicker than two
>> weeks of noise calculations..
>>
>> Conversely, in another life we were working on the design of a
>> battlefield laser rangefinder. Try as we might, we could not tweak it to
>> better than 2km range against a real target in clear air. Useless in
>> battlefield conditions.
>>
>> A consultant arrived, and asked two questions 'what power is the laser'
>> ' what is the noise figure of the photodetector' and after about two
>> minutes with a slide rule said 'that should represent a theoretical
>> maximum effective range of about..1.5km'.
>>
>> Theory is mostly good it seems at telling you what is possible and what
>> is not, but sometimes it isn't much help in achieving it. Especially if
>> your problem isn't well represented by the theory.
> 
> Wow, interesting fields you've worked in.  Point taken.  I would take
> the former solution if I could find it or happen to think of it, but
> barring that, I'm just going to work my way through theory until I
> resolve the whole situation in my own mind.  If no solution is
> possible, then I have to find proof that it isn't possible, or die
> trying.  Giving up and living with the mismatch is simply not an
> option for me.  Fortunately, my recent studies resolved a lot, so I
> feel like I've got a good grip on the issue.  That illusion will
> probably break soon, as it has done before, and then I'll hit the
> books again.


Oh, and BTW - the reason he's worked in so many fields is because he 
hasn't been able to find one he can do right.  He's proven he's not the 
electrical engineer he claims to be - and we already know he's no 
programmer.

That's why he uses a pseudonym in his posting - he's afraid people will 
find out he's a fake (and a liar).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Apr 3, 3:58=A0pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> Nilone wrote:
> > On Apr 3, 11:09 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> >> Nilone wrote:
> >>> On Apr 3, 3:21 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> >>>> Theory has its place. =A0However, the theories you have quoted gener=
ally
> >>>> have little application in the real world. =A0It's not criticism of =
you;
> >>>> rather it is recognition that academia really has little relationshi=
p to
> >>>> anything outside if its own little world.
> >>> To me, those theories seem directly applicable to the problem. =A0My
> >>> understanding of the relational model directly affects how I design m=
y
> >>> tables and write my queries. =A0Understanding the difference between
> >>> algebraic and coalgebraic structures resolved issues I had with
> >>> knowing when and how to use classes and inheritance, and it explained
> >>> why classes don't map to tables.
> >> I'm glad you think they are applicable. =A0But they really have no pla=
ce
> >> in practical programming. =A0Understanding the concept of objects and
> >> inheritance does help - just like understanding the concept of
> >> functional programming does. =A0However, there is nothing algebraic or
> >> coalgebraic about it.
>
> >> And as I said before - mapping classes to a non-OO database is fitting=
 a
> >> square peg into a round hole. =A0No matter how you twist and turn, it
> >> never fits quite right. =A0It is, however, something we have to make w=
ork.
>
> >>>> Which is why I recommended some good practical books. =A0Rather than=
 just
> >>>> give you some abstract concepts, they will show you how the applicat=
ions
> >>>> were designed - but more importantly, they will take you though the =
hows
> >>>> and whys of decisions which were made during the process.
> >>> I've tried that in the past, more than once. =A0Other solutions never
> >>> correspond exactly to mine, and when I try to adapt them, it breaks
> >>> the relationships that make them work.
> >> As I said before - there are many ways of doing the same thing. =A0 Bu=
t
> >> I'm not saying you should try to adapt other solutions to your needs -
> >> especially when they don't directly correspond to what you need.
> >> Rather, you need to *understand* the design, the choices which were ma=
de
> >> during the design, and most importantly, *why* those choices were made=
..
>
> >> You can study the theory of how to drive a car all you want; only by
> >> getting behind the wheel will you become a good driver. =A0And it help=
s if
> >> you have a good teacher.
>
> > Sigh. =A0Instead of asking why I hold my views, you contradict me by
> > repeating what you've said before. =A0I appreciate your attempt to help=
,
> > but I think differently than you do, and you're not providing what I
> > need to understand. =A0Let's end this thread.
>
> Sign. =A0Instead of trying to think differently, you keep thinking the
> same way. =A0That's why you're making the same mistakes time and time
> again - you keep doing what you're doing, and you'll keep getting what
> you got.
>
> What I am trying to do is help you change your thinking. =A0But first you
> must be open to learning.

I feel like constructive progress isn't possible, so how about some
frivolity?  Here are a few questions for you, Jerry.

Was Ada Lovelace a good programmer?  How about a programmer who is
able to consistently teach others how not to program by illustrating
the wrong techniques?

Consider an array of good programmers: [P1, P2, P3].  I ask P1 for a
general solution to map classes to tables, and he fails to provide
one.  I provide P2 with an answer to the question (whether the answer
is an actual solution isn't important now).  When I ask P3 for the
solution, I get the same answer as I provided to P2.  Now, if I ask P1
for the solution again, what response should I get?

Nilone wrote:
> On Apr 3, 12:24 pm, The Natural Philosopher <t...@invalid.invalid>
> wrote:
>> No, what he *considers* to be a 'good programmer'  i.e. someone who has
>> learnt by rote what he was taught by rote, and now attempts to teach by
>> rote.
>>
>> There is a subtle but important distinction.
> 
> Like a recursively defined type, it seems to me he views a good
> programmer as one who does what other good programmers do.  Trying to
> execute the loop just brings you back to where you started.  So we
> need a fixed point.  I would have to find a good programmer who Jerry
> recognizes as a good programmer.  Then, if I could show that what I'm
> doing is similar to what he/she did, that would qualify me as one
> too.  To me, that just seems like a lot of effort to gain approval.
> 
>>> However,
>>> I'm an algebraic kind of programmer, and I really need to represent my
>>> ideas directly.  I hope my conversation with him will provide insight
>>> on the interaction of the two concepts.
>> I don't understand what you mean there, but I have also found that some
>> kinds of problems of data representation map extremely badly onto the
>> relational databases model as it currently exists in MySQL.  In
>> particular recursive hierarchies and trees and so on. And networks as such.
> 
> Right.  A lot of that would be alleviated by support for array-valued
> attributes, tuple-valued attributes, relation-valued attributes, and
> so on.  I'd like to have function-valued attributes, too.
> Unfortunately, based on history, all those features would be used
> incorrectly and be seen as detrimental.
> 
>> In such cases the solution is always a 'hack' and being a good
>> programmer, to me, means considering the situation and finding the least
>> offensive and most practical hack.
>>
>> Or ditching relational databases and designing new data structures.
>>
>> algebraic analysis and hacking are two ends of a spectrum of tools
>> available. In practical terms its not always possible to say which
>> represents the most effective route to go down. Turing etc.
>>
>> Cf. once upon a time when I was designing a VHF receiver, we had a noise
>> problem. I knew it was in the VHF part, but was too busy to tackle it as
>> I had other more urgent problems. The Management brought in a consultant
>> who said ;'wher'es the problem? 'In the third party tuner head' I
>> replied' How do you know?' 'I cant remember, but it is'
>>
>> HE went away and spent two weeks analysing my circuitry and found
>> nothing wrong..at which point I remembred 'because if you remove the
>> head and inject  a clean signal into my circuitry, the noise vanishes'
>> I said..
>>
>> Sometimes 30 seconds with a coaxial cable is a lot quicker than two
>> weeks of noise calculations..
>>
>> Conversely, in another life we were working on the design of a
>> battlefield laser rangefinder. Try as we might, we could not tweak it to
>> better than 2km range against a real target in clear air. Useless in
>> battlefield conditions.
>>
>> A consultant arrived, and asked two questions 'what power is the laser'
>> ' what is the noise figure of the photodetector' and after about two
>> minutes with a slide rule said 'that should represent a theoretical
>> maximum effective range of about..1.5km'.
>>
>> Theory is mostly good it seems at telling you what is possible and what
>> is not, but sometimes it isn't much help in achieving it. Especially if
>> your problem isn't well represented by the theory.
> 
> Wow, interesting fields you've worked in.  Point taken.  I would take
> the former solution if I could find it or happen to think of it, but
> barring that, I'm just going to work my way through theory until I
> resolve the whole situation in my own mind.  If no solution is
> possible, then I have to find proof that it isn't possible, or die
> trying.  Giving up and living with the mismatch is simply not an
> option for me.  Fortunately, my recent studies resolved a lot, so I
> feel like I've got a good grip on the issue.  That illusion will
> probably break soon, as it has done before, and then I'll hit the
> books again.

we had a problem once with mail routing. Towo of us battered away, and 
felt that we could get by with just three tables of two columns each. 
But we weren't sure enough to commit to it.

Then a mathematician wandered over, so we tossed him the problem. It 
took him only a second 'your problem is a 3x2 matrix: its completely 
determined by three tables of two columns each'


Don't you hate a smart arse?

:-)

I loved the guys I worked with then..4-5 people with really different 
angles and mutually reinforcing skills.

Nilone wrote:

> I feel like constructive progress isn't possible, so how about some
> frivolity?  Here are a few questions for you, Jerry.
> 

Do yourself a favour: put Jerry in your killfile. He is OK at peddling 
stock standard stuff to newbies, but  beyond that he hasn't anything to 
offer except patronizing insistence in his own correctness, even when 
shown to be fundamentally wrong.

On Apr 3, 6:06=A0pm, The Natural Philosopher <t...@invalid.invalid>
wrote:
>
> we had a problem once with mail routing. Towo of us battered away, and
> felt that we could get by with just three tables of two columns each.
> But we weren't sure enough to commit to it.
>
> Then a mathematician wandered over, so we tossed him the problem. It
> took him only a second 'your problem is a 3x2 matrix: its completely
> determined by three tables of two columns each'
>
> Don't you hate a smart arse?
>
> :-)
>
> I loved the guys I worked with then..4-5 people with really different
> angles and mutually reinforcing skills.

Heh, cool story.

One-trick pony that I am, I have to point out that I would have
preferred to store it as a single table containing a 3x2 array-valued
attribute, if such was possible.

On Apr 3, 6:09=A0pm, The Natural Philosopher <t...@invalid.invalid>
wrote:
> Nilone wrote:
> > I feel like constructive progress isn't possible, so how about some
> > frivolity? =A0Here are a few questions for you, Jerry.
>
> Do yourself a favour: put Jerry in your killfile. He is OK at peddling
> stock standard stuff to newbies, but =A0beyond that he hasn't anything to
> offer except patronizing insistence in his own correctness, even when
> shown to be fundamentally wrong.

I would prefer it if we could co-exist in peace, but if that isn't
possible, then I may follow your suggestion.

Nilone wrote:
> On Apr 3, 3:58 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Nilone wrote:
>>> On Apr 3, 11:09 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>> Nilone wrote:
>>>>> On Apr 3, 3:21 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>>>> Theory has its place.  However, the theories you have quoted generally
>>>>>> have little application in the real world.  It's not criticism of you;
>>>>>> rather it is recognition that academia really has little relationship to
>>>>>> anything outside if its own little world.
>>>>> To me, those theories seem directly applicable to the problem.  My
>>>>> understanding of the relational model directly affects how I design my
>>>>> tables and write my queries.  Understanding the difference between
>>>>> algebraic and coalgebraic structures resolved issues I had with
>>>>> knowing when and how to use classes and inheritance, and it explained
>>>>> why classes don't map to tables.
>>>> I'm glad you think they are applicable.  But they really have no place
>>>> in practical programming.  Understanding the concept of objects and
>>>> inheritance does help - just like understanding the concept of
>>>> functional programming does.  However, there is nothing algebraic or
>>>> coalgebraic about it.
>>>> And as I said before - mapping classes to a non-OO database is fitting a
>>>> square peg into a round hole.  No matter how you twist and turn, it
>>>> never fits quite right.  It is, however, something we have to make work.
>>>>>> Which is why I recommended some good practical books.  Rather than just
>>>>>> give you some abstract concepts, they will show you how the applications
>>>>>> were designed - but more importantly, they will take you though the hows
>>>>>> and whys of decisions which were made during the process.
>>>>> I've tried that in the past, more than once.  Other solutions never
>>>>> correspond exactly to mine, and when I try to adapt them, it breaks
>>>>> the relationships that make them work.
>>>> As I said before - there are many ways of doing the same thing.   But
>>>> I'm not saying you should try to adapt other solutions to your needs -
>>>> especially when they don't directly correspond to what you need.
>>>> Rather, you need to *understand* the design, the choices which were made
>>>> during the design, and most importantly, *why* those choices were made.
>>>> You can study the theory of how to drive a car all you want; only by
>>>> getting behind the wheel will you become a good driver.  And it helps if
>>>> you have a good teacher.
>>> Sigh.  Instead of asking why I hold my views, you contradict me by
>>> repeating what you've said before.  I appreciate your attempt to help,
>>> but I think differently than you do, and you're not providing what I
>>> need to understand.  Let's end this thread.
>> Sign.  Instead of trying to think differently, you keep thinking the
>> same way.  That's why you're making the same mistakes time and time
>> again - you keep doing what you're doing, and you'll keep getting what
>> you got.
>>
>> What I am trying to do is help you change your thinking.  But first you
>> must be open to learning.
> 
> I feel like constructive progress isn't possible, so how about some
> frivolity?  Here are a few questions for you, Jerry.
> 
> Was Ada Lovelace a good programmer?  How about a programmer who is
> able to consistently teach others how not to program by illustrating
> the wrong techniques?
>

I never saw any of Ada Lovelace's code, so I have no idea.  And whether 
a programmer can teach how NOT to do something does not say anything 
about how good a programmer is.

> Consider an array of good programmers: [P1, P2, P3].  I ask P1 for a
> general solution to map classes to tables, and he fails to provide
> one.  I provide P2 with an answer to the question (whether the answer
> is an actual solution isn't important now).  When I ask P3 for the
> solution, I get the same answer as I provided to P2.  Now, if I ask P1
> for the solution again, what response should I get?

Impossible to tell.  There may be many good solutions.  P2 and P3 may 
actually be incorrect, even though they agree.

Programming is a practical practice, not theoretical.  You can't tell 
anything from your theoretical examples.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Nilone wrote:
> On Apr 3, 6:09 pm, The Natural Philosopher <t...@invalid.invalid>
> wrote:
>> Nilone wrote:
>>> I feel like constructive progress isn't possible, so how about some
>>> frivolity?  Here are a few questions for you, Jerry.
>> Do yourself a favour: put Jerry in your killfile. He is OK at peddling
>> stock standard stuff to newbies, but  beyond that he hasn't anything to
>> offer except patronizing insistence in his own correctness, even when
>> shown to be fundamentally wrong.
> 
> I would prefer it if we could co-exist in peace, but if that isn't
> possible, then I may follow your suggestion.

We can coexist in peace.  I have not said anything denigrating about you 
or your approach.

And BTW - TNP is a well-known troll in several Usenet newsgroups.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Apr 3, 7:27=A0pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>
> We can coexist in peace. =A0I have not said anything denigrating about yo=
u
> or your approach.

I'm sure we view each other in similar light.  Still, I've gained some
insight into the mind of a business programmer, and I appreciate the
conversation.

>
> And BTW - TNP is a well-known troll in several Usenet newsgroups.

He conversed coherently with me, as have you.  I have no issue with
either of you.

Jerry Stuckle wrote:
> Nilone wrote:
>> On Apr 3, 3:58 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>> Nilone wrote:
>>>> On Apr 3, 11:09 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>>> Nilone wrote:
>>>>>> On Apr 3, 3:21 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>>>>>> Theory has its place.  However, the theories you have quoted 
>>>>>>> generally
>>>>>>> have little application in the real world.  It's not criticism of 
>>>>>>> you;
>>>>>>> rather it is recognition that academia really has little 
>>>>>>> relationship to
>>>>>>> anything outside if its own little world.
>>>>>> To me, those theories seem directly applicable to the problem.  My
>>>>>> understanding of the relational model directly affects how I 
>>>>>> design my
>>>>>> tables and write my queries.  Understanding the difference between
>>>>>> algebraic and coalgebraic structures resolved issues I had with
>>>>>> knowing when and how to use classes and inheritance, and it explained
>>>>>> why classes don't map to tables.
>>>>> I'm glad you think they are applicable.  But they really have no place
>>>>> in practical programming.  Understanding the concept of objects and
>>>>> inheritance does help - just like understanding the concept of
>>>>> functional programming does.  However, there is nothing algebraic or
>>>>> coalgebraic about it.
>>>>> And as I said before - mapping classes to a non-OO database is 
>>>>> fitting a
>>>>> square peg into a round hole.  No matter how you twist and turn, it
>>>>> never fits quite right.  It is, however, something we have to make 
>>>>> work.
>>>>>>> Which is why I recommended some good practical books.  Rather 
>>>>>>> than just
>>>>>>> give you some abstract concepts, they will show you how the 
>>>>>>> applications
>>>>>>> were designed - but more importantly, they will take you though 
>>>>>>> the hows
>>>>>>> and whys of decisions which were made during the process.
>>>>>> I've tried that in the past, more than once.  Other solutions never
>>>>>> correspond exactly to mine, and when I try to adapt them, it breaks
>>>>>> the relationships that make them work.
>>>>> As I said before - there are many ways of doing the same thing.   But
>>>>> I'm not saying you should try to adapt other solutions to your needs -
>>>>> especially when they don't directly correspond to what you need.
>>>>> Rather, you need to *understand* the design, the choices which were 
>>>>> made
>>>>> during the design, and most importantly, *why* those choices were 
>>>>> made.
>>>>> You can study the theory of how to drive a car all you want; only by
>>>>> getting behind the wheel will you become a good driver.  And it 
>>>>> helps if
>>>>> you have a good teacher.
>>>> Sigh.  Instead of asking why I hold my views, you contradict me by
>>>> repeating what you've said before.  I appreciate your attempt to help,
>>>> but I think differently than you do, and you're not providing what I
>>>> need to understand.  Let's end this thread.
>>> Sign.  Instead of trying to think differently, you keep thinking the
>>> same way.  That's why you're making the same mistakes time and time
>>> again - you keep doing what you're doing, and you'll keep getting what
>>> you got.
>>>
>>> What I am trying to do is help you change your thinking.  But first you
>>> must be open to learning.
>>
>> I feel like constructive progress isn't possible, so how about some
>> frivolity?  Here are a few questions for you, Jerry.
>>
>> Was Ada Lovelace a good programmer?  How about a programmer who is
>> able to consistently teach others how not to program by illustrating
>> the wrong techniques?
>>
> 
> I never saw any of Ada Lovelace's code, so I have no idea.  And whether 
> a programmer can teach how NOT to do something does not say anything 
> about how good a programmer is.
> 
>> Consider an array of good programmers: [P1, P2, P3].  I ask P1 for a
>> general solution to map classes to tables, and he fails to provide
>> one.  I provide P2 with an answer to the question (whether the answer
>> is an actual solution isn't important now).  When I ask P3 for the
>> solution, I get the same answer as I provided to P2.  Now, if I ask P1
>> for the solution again, what response should I get?
> 
> Impossible to tell.  There may be many good solutions.  P2 and P3 may 
> actually be incorrect, even though they agree.
> 
> Programming is a practical practice, not theoretical.  You can't tell 
> anything from your theoretical examples.
> 
> 

Or, let me rephrase that.  P2 and P3 may have a correct answer - but P1 
may come up with an equally correct and possibly better answer.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Apr 3, 7:25=A0pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>
> > Consider an array of good programmers: [P1, P2, P3]. =A0I ask P1 for a
> > general solution to map classes to tables, and he fails to provide
> > one. =A0I provide P2 with an answer to the question (whether the answer
> > is an actual solution isn't important now). =A0When I ask P3 for the
> > solution, I get the same answer as I provided to P2. =A0Now, if I ask P=
1
> > for the solution again, what response should I get?
>
> Impossible to tell. =A0There may be many good solutions. =A0P2 and P3 may
> actually be incorrect, even though they agree.

My intention was to discover if a good programmer has a value,
especially if employed in a fixed position among other programmers.
My apologies, I find such games funny. ;)

Nilone wrote:
> On Apr 3, 7:25 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>> Consider an array of good programmers: [P1, P2, P3].  I ask P1 for a
>>> general solution to map classes to tables, and he fails to provide
>>> one.  I provide P2 with an answer to the question (whether the answer
>>> is an actual solution isn't important now).  When I ask P3 for the
>>> solution, I get the same answer as I provided to P2.  Now, if I ask P1
>>> for the solution again, what response should I get?
>> Impossible to tell.  There may be many good solutions.  P2 and P3 may
>> actually be incorrect, even though they agree.
> 
> My intention was to discover if a good programmer has a value,
> especially if employed in a fixed position among other programmers.
> My apologies, I find such games funny. ;)

A good programmer always has value.  He/she may not necessarily be in 
the best position for his/her skills, but there is always value.

A poor programmer has little or no value, and may, in fact, have a 
negative value.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Sat, 03 Apr 2010 05:09:07 -0400, Jerry Stuckle wrote:

> Nilone wrote:
>
>> On Apr 3, 3:21 am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>>
>>> Which is why I recommended some good practical books. Rather than
>>> just give you some abstract concepts, they will show you how the
>>> applications were designed - but more importantly, they will take
>>> you though the hows and whys of decisions which were made during the
>>> process.
>>
>> I've tried that in the past, more than once. Other solutions never
>> correspond exactly to mine, and when I try to adapt them, it breaks
>> the relationships that make them work.
>
> As I said before - there are many ways of doing the same thing. But
> I'm not saying you should try to adapt other solutions to your needs
> - especially when they don't directly correspond to what you need.
> Rather, you need to *understand* the design, the choices which were
> made during the design, and most importantly, *why* those choices were
> made.

Key point.

If you start out failing because you have no idea what you're doing, and
decide to learn the rules, that's a goodness. However, *eventually*, the
rules reach limits. At this point, experience takes over and starts
pointing out how to bend or break rules to make it work. 

Because eventually, the relationship algebra doesn't tell you how
actually get the 12th block of 100,000 records updated in less than a
day, because the system is already managing more relationships than it
has hardware to handle. But if you break a few rules, you can get 5
million records into a scratch area in three hours, prebuild the pivots
you need so you get responses back in seconds instead of hours, and then
switch what schema is being used as "production" to keep the rollout
downtime to seconds instead of hours as well.

-- 
The pig is nothing but a giant dish which walks while waiting to be 
served.
	    --Grimod de La Reyni�re

Nilone wrote:
> On Apr 3, 6:06 pm, The Natural Philosopher <t...@invalid.invalid>
> wrote:
>> we had a problem once with mail routing. Towo of us battered away, and
>> felt that we could get by with just three tables of two columns each.
>> But we weren't sure enough to commit to it.
>>
>> Then a mathematician wandered over, so we tossed him the problem. It
>> took him only a second 'your problem is a 3x2 matrix: its completely
>> determined by three tables of two columns each'
>>
>> Don't you hate a smart arse?
>>
>> :-)
>>
>> I loved the guys I worked with then..4-5 people with really different
>> angles and mutually reinforcing skills.
> 
> Heh, cool story.
> 
> One-trick pony that I am, I have to point out that I would have
> preferred to store it as a single table containing a 3x2 array-valued
> attribute, if such was possible.


   You do realize the reason you don't want to do that is because to 
change even just one of those values, you have to read in the entire 
array, alter array, and write out the whole thing again... this is what 
RDB's are trying to avoid.

-- 
Norman
Registered Linux user #461062
-Have you been to www.mysql.com yet?-

On Apr 4, 3:42=A0pm, Norman Peelman <npeel...@cfl.rr.com> wrote:
> Nilone wrote:
>
> > One-trick pony that I am, I have to point out that I would have
> > preferred to store it as a single table containing a 3x2 array-valued
> > attribute, if such was possible.
>
> =A0 =A0You do realize the reason you don't want to do that is because to
> change even just one of those values, you have to read in the entire
> array, alter array, and write out the whole thing again... this is what
> RDB's are trying to avoid.

Not if the DB supports array algebra, e.g.

UPDATE Matrix3x2 SET value[1,2] =3D value[1,2] + 1 WHERE value[2,2] =3D 3;

You don't even have to get the array out of the DB.

Nilone wrote:
> On Apr 4, 3:42 pm, Norman Peelman <npeel...@cfl.rr.com> wrote:
>> Nilone wrote:
>>
>>> One-trick pony that I am, I have to point out that I would have
>>> preferred to store it as a single table containing a 3x2 array-valued
>>> attribute, if such was possible.
>>    You do realize the reason you don't want to do that is because to
>> change even just one of those values, you have to read in the entire
>> array, alter array, and write out the whole thing again... this is what
>> RDB's are trying to avoid.
> 
> Not if the DB supports array algebra, e.g.
> 
> UPDATE Matrix3x2 SET value[1,2] = value[1,2] + 1 WHERE value[2,2] = 3;
> 
> You don't even have to get the array out of the DB.

You can do the same thing with tables.

An array (or a tuple) is a single value ONLY if the individual parts 
cannot be accessed independently.  For instance, a floating point number 
is generally stored as exponent and mantissa.  There are two parts to it 
- but they cannot be accessed individually.

What you want is not possible in databases.  There is a solution to it - 
get on the ANSI SQL subcommittee and propose such syntax.  If enough 
people agree with you, it will become part of the SQL standard and 
database vendors will start implementing it.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Apr 4, 7:27=A0pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> Nilone wrote:
> > On Apr 4, 3:42 pm, Norman Peelman <npeel...@cfl.rr.com> wrote:
> >> Nilone wrote:
>
> >>> One-trick pony that I am, I have to point out that I would have
> >>> preferred to store it as a single table containing a 3x2 array-valued
> >>> attribute, if such was possible.
> >> =A0 =A0You do realize the reason you don't want to do that is because =
to
> >> change even just one of those values, you have to read in the entire
> >> array, alter array, and write out the whole thing again... this is wha=
t
> >> RDB's are trying to avoid.
>
> > Not if the DB supports array algebra, e.g.
>
> > UPDATE Matrix3x2 SET value[1,2] =3D value[1,2] + 1 WHERE value[2,2] =3D=
 3;
>
> > You don't even have to get the array out of the DB.
>
> You can do the same thing with tables.

I'm hesitant to reason with you, Jerry, but I'll give it one more go.
I require critical reasoning to be convinced differently.

At the moment we have to do everything with tables and simple
attributes.  That gets tedious and complex, however, like using three
tables to represent one matrix.  One of the complaints about natural
keys is that they multiply.  That's because we can't compose them into
single values.  Composite types would help to simplify databases.

>
> An array (or a tuple) is a single value ONLY if the individual parts
> cannot be accessed independently. =A0For instance, a floating point numbe=
r
> is generally stored as exponent and mantissa. =A0There are two parts to i=
t
> - but they cannot be accessed individually.

Consider what makes two instances of a value the same value, or
different values.  The encoding of a value, and our ability to access
it, doesn't affect it.  A value can have different encodings in some
cases and still be the same value.  Even if I can access or derive the
bits of floating point numbers and integers, they would still be
values.

Natural or derivable attributes of a value aren't a problem either.
Attributes of a value can be generalized to functions from the value
to another domain.  Deriving one value from another doesn't affect the
status of either as values.  For example, I can derive the prime
factors of an integer, or the digits of a number in any base and
encoding, via arithmetic, but I still consider numbers as values.

A value isn't a value because it can't be decomposed, but because it
exists in a defined domain and can be compared for equality with other
elements of the domain.  For example, take values of different types,
e.g. integer and string.  Comparing them requires that one be cast to
the domain of the other, which means finding it's projection in
another domain.  If there's a general conversion function from one
domain to another, we can compare values of those types, otherwise we
can't.

>
> What you want is not possible in databases. =A0There is a solution to it =
-
> get on the ANSI SQL subcommittee and propose such syntax. =A0If enough
> people agree with you, it will become part of the SQL standard and
> database vendors will start implementing it.

There is currently no dbms that supports what I want, and I see no
hope of changing the SQL standard to get it, since some of what I want
would break backwards compatibility.  Improving people's understanding
of the relevant concepts (mine included) is the best path for now.  I
may eventually write my own dbms as a proof of concept.

Nilone wrote:
> On Apr 4, 7:27 pm, Jerry Stuckle <jstuck...@attglobal.net> wrote:
>> Nilone wrote:
>>> On Apr 4, 3:42 pm, Norman Peelman <npeel...@cfl.rr.com> wrote:
>>>> Nilone wrote:
>>>>> One-trick pony that I am, I have to point out that I would have
>>>>> preferred to store it as a single table containing a 3x2 array-valued
>>>>> attribute, if such was possible.
>>>>    You do realize the reason you don't want to do that is because to
>>>> change even just one of those values, you have to read in the entire
>>>> array, alter array, and write out the whole thing again... this is what
>>>> RDB's are trying to avoid.
>>> Not if the DB supports array algebra, e.g.
>>> UPDATE Matrix3x2 SET value[1,2] = value[1,2] + 1 WHERE value[2,2] = 3;
>>> You don't even have to get the array out of the DB.
>> You can do the same thing with tables.
> 
> I'm hesitant to reason with you, Jerry, but I'll give it one more go.
> I require critical reasoning to be convinced differently.

Quite frankly, I don't give a damn if you are convinced differently or 
not.  I'm just telling it like it is.  It's up to you to accept or 
reject it.

It's your grave you're digging, not anyone else's.

> 
> At the moment we have to do everything with tables and simple
> attributes.  That gets tedious and complex, however, like using three
> tables to represent one matrix.  One of the complaints about natural
> keys is that they multiply.  That's because we can't compose them into
> single values.  Composite types would help to simplify databases.
> 
>> An array (or a tuple) is a single value ONLY if the individual parts
>> cannot be accessed independently.  For instance, a floating point number
>> is generally stored as exponent and mantissa.  There are two parts to it
>> - but they cannot be accessed individually.
> 
> Consider what makes two instances of a value the same value, or
> different values.  The encoding of a value, and our ability to access
> it, doesn't affect it.  A value can have different encodings in some
> cases and still be the same value.  Even if I can access or derive the
> bits of floating point numbers and integers, they would still be
> values.
>

If they have different bit patterns, they are by definition different 
values.  Encoding is only relevant in how the values are used.  The same 
value may have many different meanings, depending on the encoding.

> Natural or derivable attributes of a value aren't a problem either.
> Attributes of a value can be generalized to functions from the value
> to another domain.  Deriving one value from another doesn't affect the
> status of either as values.  For example, I can derive the prime
> factors of an integer, or the digits of a number in any base and
> encoding, via arithmetic, but I still consider numbers as values.
> 
> A value isn't a value because it can't be decomposed, but because it
> exists in a defined domain and can be compared for equality with other
> elements of the domain.  For example, take values of different types,
> e.g. integer and string.  Comparing them requires that one be cast to
> the domain of the other, which means finding it's projection in
> another domain.  If there's a general conversion function from one
> domain to another, we can compare values of those types, otherwise we
> can't.
> 

Whether they are different types and can or cannot be compared with 
another value of a different type is completely immaterial to whether it 
is a value or not.  Those are run-time conversion, and have no bearing 
on whether something is a value or not.

>> What you want is not possible in databases.  There is a solution to it -
>> get on the ANSI SQL subcommittee and propose such syntax.  If enough
>> people agree with you, it will become part of the SQL standard and
>> database vendors will start implementing it.
> 
> There is currently no dbms that supports what I want, and I see no
> hope of changing the SQL standard to get it, since some of what I want
> would break backwards compatibility.  Improving people's understanding
> of the relevant concepts (mine included) is the best path for now.  I
> may eventually write my own dbms as a proof of concept.

Done correctly, it does not need to break backwards compatibility.

As to the rest - it doesn't matter what you want.  If you aren't willing 
to try to get changes made, then you have to deal with what's available.

But you really seem to have some basic misunderstandings of data in 
general.  I don't see that you are willing to learn - only "be 
convinced".  I'm really not interested in that.

I'm out of here.  Good luck.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Apr 5, 2:37=A0am, Jerry Stuckle <jstuck...@attglobal.net> wrote:
> Nilone wrote:
>
> > I'm hesitant to reason with you, Jerry, but I'll give it one more go.
> > I require critical reasoning to be convinced differently.
>
> Quite frankly, I don't give a damn if you are convinced differently or
> not. =A0I'm just telling it like it is. =A0It's up to you to accept or
> reject it.

I, too, believe that I'm telling it as it is, yet our points of view
differ.  Do we attempt to resolve the difference, and risk learning
something, or do we go our separate ways, one or both of us
confidently ignorant?

>
> It's your grave you're digging, not anyone else's.

If I'm proven wrong, that's to my advantage, since I'll know what to
study next to improve my understanding.  I can't lose, except by not
playing.

>
> If they have different bit patterns, they are by definition different
> values.

Consider the following encoded bit-patterns in 8 bits:

10000001 in signed magnitude
11111111 in two's complement
11111110 in one's complement

They all encode the integer value -1.

>=A0Encoding is only relevant in how the values are used. =A0The same
> value may have many different meanings, depending on the encoding.

Perhaps we differ only in terminology.  What you call meaning may be
what I call value, while your value may be my encoding.  If so, do you
still disagree?

>
> > A value isn't a value because it can't be decomposed, but because it
> > exists in a defined domain and can be compared for equality with other
> > elements of the domain. =A0For example, take values of different types,
> > e.g. integer and string. =A0Comparing them requires that one be cast to
> > the domain of the other, which means finding it's projection in
> > another domain. =A0If there's a general conversion function from one
> > domain to another, we can compare values of those types, otherwise we
> > can't.
>
> Whether they are different types and can or cannot be compared with
> another value of a different type is completely immaterial to whether it
> is a value or not. =A0Those are run-time conversion, and have no bearing
> on whether something is a value or not.

You're right.

>
> > There is currently no dbms that supports what I want, and I see no
> > hope of changing the SQL standard to get it, since some of what I want
> > would break backwards compatibility. =A0Improving people's understandin=
g
> > of the relevant concepts (mine included) is the best path for now. =A0I
> > may eventually write my own dbms as a proof of concept.
>
> Done correctly, it does not need to break backwards compatibility.

For arrays, I agree.  I have some more extensive redesigns in mind,
though.

>
> As to the rest - it doesn't matter what you want. =A0If you aren't willin=
g
> to try to get changes made, then you have to deal with what's available.

I do intend to make changes, but first I must correctly define and
illustrate the solution.  It's not something I want decided by
committee and voting, but by undeniable logic.

>
> But you really seem to have some basic misunderstandings of data in
> general. =A0I don't see that you are willing to learn - only "be
> convinced". =A0I'm really not interested in that.

I suppose I could have just asked "how is a floating point not a value
when functions or attributes exist to inspect or derive its exponent
and mantissa", and let you do the work of explaining.  Instead, I
explained my point of view and gave you ample opportunity to show the
flaws in my reasoning.  Surely, if my misunderstanding is so obvious,
then at some point someone should be able to point and say "that
doesn't follow".

>
> I'm out of here. =A0Good luck.

It seems we'll go our separate ways, and one or both of us will remain
confidently ignorant.  I wish you well.