Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #12467 > unrolled thread

Loop through array, change headings

Back to article view | Back to comp.lang.php

Contents

  Loop through array, change headings Adrienne Boswell <arbpen@yahoo.com> - 2013-12-31 21:08 +0000
    Re: Loop through array, change headings Denis McMahon <denismfmcmahon@gmail.com> - 2013-12-31 21:22 +0000
      Re: Loop through array, change headings Adrienne Boswell <arbpen@yahoo.com> - 2013-12-31 23:40 +0000
    Re: Loop through array, change headings richard <noreply@example.com> - 2013-12-31 17:06 -0500
      Re: Loop through array, change headings Denis McMahon <denismfmcmahon@gmail.com> - 2013-12-31 23:00 +0000
        Re: Loop through array, change headings richard <noreply@example.com> - 2013-12-31 19:19 -0500
          Re: Loop through array, change headings Denis McMahon <denismfmcmahon@gmail.com> - 2014-01-01 00:39 +0000
          Re: Loop through array, change headings "Beauregard T. Shagnasty" <a.nony.mous@example.invalid> - 2014-01-01 00:56 +0000
          Re: Loop through array, change headings Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-31 20:50 -0500
            Re: Loop through array, change headings richard <noreply@example.com> - 2013-12-31 21:08 -0500
              Re: Loop through array, change headings Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-31 21:43 -0500
              Re: Loop through array, change headings "Beauregard T. Shagnasty" <a.nony.mous@example.invalid> - 2014-01-01 03:24 +0000
              Re: Loop through array, change headings Denis McMahon <denismfmcmahon@gmail.com> - 2014-01-01 03:26 +0000
          Re: Loop through array, change headings Arno Welzel <usenet@arnowelzel.de> - 2014-01-01 18:01 +0100
          Re: Loop through array, change headings Norman Peelman <npeelman@cfl.rr.com> - 2014-01-02 06:23 -0500
            Re: Loop through array, change headings Denis McMahon <denismfmcmahon@gmail.com> - 2014-01-02 13:09 +0000
              Re: Loop through array, change headings "Peter H. Coffin" <hellsop@ninehells.com> - 2014-01-02 09:20 -0600
                Re: Loop through array, change headings "Beauregard T. Shagnasty" <a.nony.mous@example.invalid> - 2014-01-02 15:39 +0000
                  Re: Loop through array, change headings Jerry Stuckle <jstucklex@attglobal.net> - 2014-01-02 10:52 -0500
                    Re: Loop through array, change headings "Beauregard T. Shagnasty" <a.nony.mous@example.invalid> - 2014-01-02 16:43 +0000
                    Re: Loop through array, change headings "Peter H. Coffin" <hellsop@ninehells.com> - 2014-01-05 18:23 -0600
                      Re: Loop through array, change headings "Peter H. Coffin" <hellsop@ninehells.com> - 2014-01-05 18:37 -0600
                Re: Loop through array, change headings Denis McMahon <denismfmcmahon@gmail.com> - 2014-01-02 18:04 +0000
      Re: Loop through array, change headings Arno Welzel <usenet@arnowelzel.de> - 2014-01-01 17:56 +0100

Page 1 of 2  [1] 2  Next page →

#12467 — Loop through array, change headings

I'm sure this has been asked and answered, but I am either too stupid to 
figure out the right way to ask Google, or I'm lazy, or it really hasn't 
been asked.  Sorry in advance, and if it has been answered, please refer 
me as needed.

Here's my situation:
I have a table that has three classifications:
    id Classification
    1  Stores
    2  Restaurants
    3  Services

I have another table that has categories in each classification, eg.
    id Category Classification_id
    1  Market   1
    2  Pet Shop 1
    3  Pizza    2
    4  Sandwich 2
    5  Notary   3
    6  Repair   3

My query is 
    SELECT c.id, category, classification, cl.id AS classid FROM category 
c JOIN classification cl ON c.classification_id = cl.id ORDER BY classid, 
category

What I want to do is:
-Stores
Market
Pet Shop
-Restaurants
Pizza
Sandwich
-Services
Notary
Repair


So, as I'm looping through my recordset, if the classid has changed, I 
want to change the header. I don't want to make one query to get the 
headings, and then do another query for each classid.  I KNOW there has 
got to be a better way.

I'm trying to get this all done so I can have a Happy New Year, and 
wishing you and yours a Happy New Year as well.

-- 
Adrienne Boswell
Arbpen Web Site Design Services - http://www.cavalcade-of-coding.info/
The Good Plate - Fresh Gourmet Recipes - http://the-good-plate.com/
Please respond to the group so others can share

[toc] | [next] | [standalone]

#12468

On Tue, 31 Dec 2013 21:08:42 +0000, Adrienne Boswell wrote:

> So, as I'm looping through my recordset, if the classid has changed, I
> want to change the header. I don't want to make one query to get the
> headings, and then do another query for each classid.  I KNOW there has
> got to be a better way.

Something like the following (untested, may not use the right call names 
etc) php:

$class = "";
while ( $row = result->get_row_assoc() !== false ) {
  if ( $class != $row["classification"] ) {
    $class = $row["classification"];
    output "-" . $class . "\n";
  }
  output "    " . $row["category"];
}

Loop through the result set, every time the class of the record doesn't 
match the existing class, output the class header.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#12472

Denis McMahon <denismfmcmahon@gmail.com> wrote

> On Tue, 31 Dec 2013 21:08:42 +0000, Adrienne Boswell wrote:
> 
>> So, as I'm looping through my recordset, if the classid has changed, I
>> want to change the header. I don't want to make one query to get the
>> headings, and then do another query for each classid.  I KNOW there 
has
>> got to be a better way.
> 
> Something like the following (untested, may not use the right call 
names 
> etc) php:
> 
> $class = "";
> while ( $row = result->get_row_assoc() !== false ) {
>   if ( $class != $row["classification"] ) {
>     $class = $row["classification"];
>     output "-" . $class . "\n";
>   }
>   output "    " . $row["category"];
> }
> 
> Loop through the result set, every time the class of the record doesn't 
> match the existing class, output the class header.
> 

Dennis, thank you so much, that worked beautifully! 

-- 
Adrienne Boswell
Arbpen Web Site Design Services - http://www.cavalcade-of-coding.info/
The Good Plate - Fresh Gourmet Recipes - http://the-good-plate.com/
Please respond to the group so others can share

[toc] | [prev] | [next] | [standalone]

#12470

On Tue, 31 Dec 2013 21:08:42 +0000 (UTC), Adrienne Boswell wrote:

> I'm sure this has been asked and answered, but I am either too stupid to 
> figure out the right way to ask Google, or I'm lazy, or it really hasn't 
> been asked.  Sorry in advance, and if it has been answered, please refer 
> me as needed.
> 
> Here's my situation:
> I have a table that has three classifications:
>     id Classification
>     1  Stores
>     2  Restaurants
>     3  Services
> 
> I have another table that has categories in each classification, eg.
>     id Category Classification_id
>     1  Market   1
>     2  Pet Shop 1
>     3  Pizza    2
>     4  Sandwich 2
>     5  Notary   3
>     6  Repair   3
> 
> My query is 
>     SELECT c.id, category, classification, cl.id AS classid FROM category 
> c JOIN classification cl ON c.classification_id = cl.id ORDER BY classid, 
> category
> 
> What I want to do is:
> -Stores
> Market
> Pet Shop
> -Restaurants
> Pizza
> Sandwich
> -Services
> Notary
> Repair
> 
> 
> So, as I'm looping through my recordset, if the classid has changed, I 
> want to change the header. I don't want to make one query to get the 
> headings, and then do another query for each classid.  I KNOW there has 
> got to be a better way.
> 
> I'm trying to get this all done so I can have a Happy New Year, and 
> wishing you and yours a Happy New Year as well.

Why not have one table?
id | stores | restaurant | services

if you wanted to include actual names of
:
type       | class | name
_______________________________________
stores     |       | 
Restarants |       |
Services   |       |

You could have as many "stores" and such as needed.
(simplified)
while (type==stores){echo 'class'; echo 'name'}

[toc] | [prev] | [next] | [standalone]

#12471

On Tue, 31 Dec 2013 17:06:38 -0500, richard wrote:

> On Tue, 31 Dec 2013 21:08:42 +0000 (UTC), Adrienne Boswell wrote:

>> I have a table that has three classifications.

>> I have another table that has categories in each classification.

> Why not have one table?

Richard, you've proved time and time again that you have no understanding 
of relational database design theory. Please stop trying to suggest that 
people with sensibly designed databases should do it the stoopid way.

Adrienne's query joins the multiple tables into a single dataset and 
sorts the dataset, the question asked was how to process that sorted 
dataset in a specific manner. The question has nothing to do with the 
structure of the data in the database, the answer lies solely in how the 
result object returned by the mysql[i]->query() is processed.

Here's one example of why Adriennes approach is easier:

Supposing Adrienne decides to rename one of the three classifications. In 
Adriennes database, that involves a single sql operation on one row in 
one table. In your hypothetical and seriously fucked up database design, 
you would need to test each row in the whole database to see if the 
category was the one that needed to be changed, and then change it. Such 
a process is highly inefficient in terms of both cpu effort, memory 
management and disk io, and it is to prevent such inefficiencies amongst 
other things that relational database design theory has evolved to where 
it is today.

Unlike your comprehension of computer systems which appears to have 
started at nothing and continues to devolve backwards.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#12473

On Tue, 31 Dec 2013 23:00:32 +0000 (UTC), Denis McMahon wrote:

> On Tue, 31 Dec 2013 17:06:38 -0500, richard wrote:
> 
>> On Tue, 31 Dec 2013 21:08:42 +0000 (UTC), Adrienne Boswell wrote:
> 
>>> I have a table that has three classifications.
> 
>>> I have another table that has categories in each classification.
> 
>> Why not have one table?
> 
> Richard, you've proved time and time again that you have no understanding 
> of relational database design theory. Please stop trying to suggest that 
> people with sensibly designed databases should do it the stoopid way.
> 
> Adrienne's query joins the multiple tables into a single dataset and 
> sorts the dataset, the question asked was how to process that sorted 
> dataset in a specific manner. The question has nothing to do with the 
> structure of the data in the database, the answer lies solely in how the 
> result object returned by the mysql[i]->query() is processed.
> 
> Here's one example of why Adriennes approach is easier:
> 
> Supposing Adrienne decides to rename one of the three classifications. In 
> Adriennes database, that involves a single sql operation on one row in 
> one table. In your hypothetical and seriously fucked up database design, 
> you would need to test each row in the whole database to see if the 
> category was the one that needed to be changed, and then change it. Such 
> a process is highly inefficient in terms of both cpu effort, memory 
> management and disk io, and it is to prevent such inefficiencies amongst 
> other things that relational database design theory has evolved to where 
> it is today.
> 
> Unlike your comprehension of computer systems which appears to have 
> started at nothing and continues to devolve backwards.

I was merely suggesting one possible way.
I have never liked the idea of making two tables where one is sufficient.

In the OP's example, we have going on exactly what you speak of.
Let's say he wants to add on a second pet shop
Now he has to change the id's in two tables.
Plus, the remaining id's all have to be changed accordingly.
So what if he has 1,000 rows?
He made a change on row 5. So now the sequence of events has to change
1990+ items?

In my example, if you want to add on another pet store, all you do is
insert the new row and increment the id's.

Otherwise, he should have a table for each category.
Forget cross referencing with id's.

[toc] | [prev] | [next] | [standalone]

#12474

On Tue, 31 Dec 2013 19:19:27 -0500, richard wrote:

> On Tue, 31 Dec 2013 23:00:32 +0000 (UTC), Denis McMahon wrote:
> 
>> On Tue, 31 Dec 2013 17:06:38 -0500, richard wrote:
>> 
>>> On Tue, 31 Dec 2013 21:08:42 +0000 (UTC), Adrienne Boswell wrote:
>> 
>>>> I have a table that has three classifications.
>> 
>>>> I have another table that has categories in each classification.
>> 
>>> Why not have one table?
>> 
>> Richard, you've proved time and time again that you have no
>> understanding of relational database design theory. Please stop trying
>> to suggest that people with sensibly designed databases should do it
>> the stoopid way.
>> 
>> Adrienne's query joins the multiple tables into a single dataset and
>> sorts the dataset, the question asked was how to process that sorted
>> dataset in a specific manner. The question has nothing to do with the
>> structure of the data in the database, the answer lies solely in how
>> the result object returned by the mysql[i]->query() is processed.
>> 
>> Here's one example of why Adriennes approach is easier:
>> 
>> Supposing Adrienne decides to rename one of the three classifications.
>> In Adriennes database, that involves a single sql operation on one row
>> in one table. In your hypothetical and seriously fucked up database
>> design, you would need to test each row in the whole database to see if
>> the category was the one that needed to be changed, and then change it.
>> Such a process is highly inefficient in terms of both cpu effort,
>> memory management and disk io, and it is to prevent such inefficiencies
>> amongst other things that relational database design theory has evolved
>> to where it is today.
>> 
>> Unlike your comprehension of computer systems which appears to have
>> started at nothing and continues to devolve backwards.
> 
> I was merely suggesting one possible way.
> I have never liked the idea of making two tables where one is
> sufficient.
> 
> In the OP's example, we have going on exactly what you speak of.
> Let's say he wants to add on a second pet shop Now he has to change the
> id's in two tables.

No the OP doesn't. If the OP wants to add a new category eg "Hat shop" in 
classification 1 the OP goes from this:

cl / classification

    id Classification
    1  Stores
    2  Restaurants
    3  Services

c / category

    id Category Classification_id 
    1  Market   1
    2  Pet Shop 1
    3  Pizza    2
    4  Sandwich 2
    5  Notary   3
    6  Repair   3

To this:

cl / classification

    id Classification
    1  Stores
    2  Restaurants
    3  Services

c / category

    id Category Classification_id 
    1  Market   1
    2  Pet Shop 1
    3  Pizza    2
    4  Sandwich 2
    5  Notary   3
    6  Repair   3
    7  Hat shop 1

There is no need to have multiple "pet shop" categories. All pet shops 
are of category "pet shop". The actual shop is probably in another table 
which has shop details and category id.

eg: Establishments:

    id    Name               Category id
    1     smart pets         2
    2     bettah pets        2
    3     pets-r-us          2
    4     toppers            7
    5     silk fascination   7
    6     flowers on top     7
    7     subway             4
    8     rolls-4-u          4
    9     bagels-away        4
    10    easy-wills         5

And if the OP wants to add a new pet store they can add:

    11    cats and dogs      2

Without needing to change anything in the other two tables.

And that is why you completely fail to understand how databases work.

> Plus, the remaining id's all have to be changed accordingly.

No, no other ids need to change at all.

> So what if he has 1,000 rows?

What if they do?

> He made a change on row 5. So now the sequence of events has to change
> 1990+ items?

Not at all. If the OP wants to reclassify the category "pet shop" from 
"store" to "services", they merely need to change the classification id 
of the category "pet shop" in the category table from the id of "stores" 
in the classifications table to that of "services", and all pet shops 
will be changed from stores to services.

> In my example, if you want to add on another pet store, all you do is
> insert the new row and increment the id's.

In the OPs example, their data doesn't extend to showing individual 
stores, it only shows categories of establishment, and wider 
classifications that those categories are grouped into.

> Otherwise, he should have a table for each category.

It is your flawed understanding of database concepts that leads you to 
think this way. The more you try and explain why you think your way is 
best, the more you demonstrate your complete lack of comprehension of 
databases.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#12475

richard the sto0pid wrote:

> Denis McMahon wrote, to richard the sto0pid:
>> Unlike your comprehension of computer systems which appears to have
>> started at nothing and continues to devolve backwards.
> 
> I was merely suggesting one possible way.
> I have never liked the idea of making two tables where one is
> sufficient.

Bullis, meet Dr. E. F. Codd.

Look up, for example, "Third Normal Form."

Oh wait ... that will be *completely* beyond your understanding.

-- 
   -bts
   -This space for rent, but the price is high

[toc] | [prev] | [next] | [standalone]

#12477

On 12/31/2013 7:19 PM, richard wrote:
> On Tue, 31 Dec 2013 23:00:32 +0000 (UTC), Denis McMahon wrote:
>
>> On Tue, 31 Dec 2013 17:06:38 -0500, richard wrote:
>>
>>> On Tue, 31 Dec 2013 21:08:42 +0000 (UTC), Adrienne Boswell wrote:
>>
>>>> I have a table that has three classifications.
>>
>>>> I have another table that has categories in each classification.
>>
>>> Why not have one table?
>>
>> Richard, you've proved time and time again that you have no understanding
>> of relational database design theory. Please stop trying to suggest that
>> people with sensibly designed databases should do it the stoopid way.
>>
>> Adrienne's query joins the multiple tables into a single dataset and
>> sorts the dataset, the question asked was how to process that sorted
>> dataset in a specific manner. The question has nothing to do with the
>> structure of the data in the database, the answer lies solely in how the
>> result object returned by the mysql[i]->query() is processed.
>>
>> Here's one example of why Adriennes approach is easier:
>>
>> Supposing Adrienne decides to rename one of the three classifications. In
>> Adriennes database, that involves a single sql operation on one row in
>> one table. In your hypothetical and seriously fucked up database design,
>> you would need to test each row in the whole database to see if the
>> category was the one that needed to be changed, and then change it. Such
>> a process is highly inefficient in terms of both cpu effort, memory
>> management and disk io, and it is to prevent such inefficiencies amongst
>> other things that relational database design theory has evolved to where
>> it is today.
>>
>> Unlike your comprehension of computer systems which appears to have
>> started at nothing and continues to devolve backwards.
>
> I was merely suggesting one possible way.
> I have never liked the idea of making two tables where one is sufficient.
>

You were suggesting a way which proves you have NO IDEA of what RELATION 
database design mean.

For instance, in YOUR design, what happens if he has no restaurants in 
the current classification?

> In the OP's example, we have going on exactly what you speak of.
> Let's say he wants to add on a second pet shop
> Now he has to change the id's in two tables.
> Plus, the remaining id's all have to be changed accordingly.
> So what if he has 1,000 rows?
> He made a change on row 5. So now the sequence of events has to change
> 1990+ items?
>

He needs to add the pet shop in one table and a relationship entity in a 
second table.  That's what RELATIONAL means.

> In my example, if you want to add on another pet store, all you do is
> insert the new row and increment the id's.
>
> Otherwise, he should have a table for each category.
> Forget cross referencing with id's.
>

This is beyond STOOPID!

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

[toc] | [prev] | [next] | [standalone]

#12478

On Tue, 31 Dec 2013 20:50:31 -0500, Jerry Stuckle wrote:

> On 12/31/2013 7:19 PM, richard wrote:
>> On Tue, 31 Dec 2013 23:00:32 +0000 (UTC), Denis McMahon wrote:
>>
>>> On Tue, 31 Dec 2013 17:06:38 -0500, richard wrote:
>>>
>>>> On Tue, 31 Dec 2013 21:08:42 +0000 (UTC), Adrienne Boswell wrote:
>>>
>>>>> I have a table that has three classifications.
>>>
>>>>> I have another table that has categories in each classification.
>>>
>>>> Why not have one table?
>>>
>>> Richard, you've proved time and time again that you have no understanding
>>> of relational database design theory. Please stop trying to suggest that
>>> people with sensibly designed databases should do it the stoopid way.
>>>
>>> Adrienne's query joins the multiple tables into a single dataset and
>>> sorts the dataset, the question asked was how to process that sorted
>>> dataset in a specific manner. The question has nothing to do with the
>>> structure of the data in the database, the answer lies solely in how the
>>> result object returned by the mysql[i]->query() is processed.
>>>
>>> Here's one example of why Adriennes approach is easier:
>>>
>>> Supposing Adrienne decides to rename one of the three classifications. In
>>> Adriennes database, that involves a single sql operation on one row in
>>> one table. In your hypothetical and seriously fucked up database design,
>>> you would need to test each row in the whole database to see if the
>>> category was the one that needed to be changed, and then change it. Such
>>> a process is highly inefficient in terms of both cpu effort, memory
>>> management and disk io, and it is to prevent such inefficiencies amongst
>>> other things that relational database design theory has evolved to where
>>> it is today.
>>>
>>> Unlike your comprehension of computer systems which appears to have
>>> started at nothing and continues to devolve backwards.
>>
>> I was merely suggesting one possible way.
>> I have never liked the idea of making two tables where one is sufficient.
>>
> 
> You were suggesting a way which proves you have NO IDEA of what RELATION 
> database design mean.
> 
> For instance, in YOUR design, what happens if he has no restaurants in 
> the current classification?
> 
>> In the OP's example, we have going on exactly what you speak of.
>> Let's say he wants to add on a second pet shop
>> Now he has to change the id's in two tables.
>> Plus, the remaining id's all have to be changed accordingly.
>> So what if he has 1,000 rows?
>> He made a change on row 5. So now the sequence of events has to change
>> 1990+ items?
>>
> 
> He needs to add the pet shop in one table and a relationship entity in a 
> second table.  That's what RELATIONAL means.
> 
>> In my example, if you want to add on another pet store, all you do is
>> insert the new row and increment the id's.
>>
>> Otherwise, he should have a table for each category.
>> Forget cross referencing with id's.
>>
> 
> This is beyond STOOPID!

well duhh, jerry stickett, whenever a data cell has no value, the returned
value is zero or null.


Suppose I had a table that had 12 columns and 365 rows.
Which would represent a calendar.
What data would be in the cell for Feb, 31?

There would be data only in the cells for that given column. 



row1 would be Jan 1, column 1. 
row1 coluimns 2 through 12 would be blank.

According to you, I would need 12 tables.

[toc] | [prev] | [next] | [standalone]

#12479

On 12/31/2013 9:08 PM, richard wrote:
> On Tue, 31 Dec 2013 20:50:31 -0500, Jerry Stuckle wrote:
>
>> On 12/31/2013 7:19 PM, richard wrote:
>>> On Tue, 31 Dec 2013 23:00:32 +0000 (UTC), Denis McMahon wrote:
>>>
>>>> On Tue, 31 Dec 2013 17:06:38 -0500, richard wrote:
>>>>
>>>>> On Tue, 31 Dec 2013 21:08:42 +0000 (UTC), Adrienne Boswell wrote:
>>>>
>>>>>> I have a table that has three classifications.
>>>>
>>>>>> I have another table that has categories in each classification.
>>>>
>>>>> Why not have one table?
>>>>
>>>> Richard, you've proved time and time again that you have no understanding
>>>> of relational database design theory. Please stop trying to suggest that
>>>> people with sensibly designed databases should do it the stoopid way.
>>>>
>>>> Adrienne's query joins the multiple tables into a single dataset and
>>>> sorts the dataset, the question asked was how to process that sorted
>>>> dataset in a specific manner. The question has nothing to do with the
>>>> structure of the data in the database, the answer lies solely in how the
>>>> result object returned by the mysql[i]->query() is processed.
>>>>
>>>> Here's one example of why Adriennes approach is easier:
>>>>
>>>> Supposing Adrienne decides to rename one of the three classifications. In
>>>> Adriennes database, that involves a single sql operation on one row in
>>>> one table. In your hypothetical and seriously fucked up database design,
>>>> you would need to test each row in the whole database to see if the
>>>> category was the one that needed to be changed, and then change it. Such
>>>> a process is highly inefficient in terms of both cpu effort, memory
>>>> management and disk io, and it is to prevent such inefficiencies amongst
>>>> other things that relational database design theory has evolved to where
>>>> it is today.
>>>>
>>>> Unlike your comprehension of computer systems which appears to have
>>>> started at nothing and continues to devolve backwards.
>>>
>>> I was merely suggesting one possible way.
>>> I have never liked the idea of making two tables where one is sufficient.
>>>
>>
>> You were suggesting a way which proves you have NO IDEA of what RELATION
>> database design mean.
>>
>> For instance, in YOUR design, what happens if he has no restaurants in
>> the current classification?
>>
>>> In the OP's example, we have going on exactly what you speak of.
>>> Let's say he wants to add on a second pet shop
>>> Now he has to change the id's in two tables.
>>> Plus, the remaining id's all have to be changed accordingly.
>>> So what if he has 1,000 rows?
>>> He made a change on row 5. So now the sequence of events has to change
>>> 1990+ items?
>>>
>>
>> He needs to add the pet shop in one table and a relationship entity in a
>> second table.  That's what RELATIONAL means.
>>
>>> In my example, if you want to add on another pet store, all you do is
>>> insert the new row and increment the id's.
>>>
>>> Otherwise, he should have a table for each category.
>>> Forget cross referencing with id's.
>>>
>>
>> This is beyond STOOPID!
>
> well duhh, jerry stickett, whenever a data cell has no value, the returned
> value is zero or null.
>

You don't even understand the question, RTS!

Here's a hint: In your design, if there were no restaurants, there would 
be no restaurant category.

>
> Suppose I had a table that had 12 columns and 365 rows.
> Which would represent a calendar.
> What data would be in the cell for Feb, 31?
>

You tell me.  I wouldn't even try to design a database in such a stoopid 
way.

> There would be data only in the cells for that given column.
>
>
>
> row1 would be Jan 1, column 1.
> row1 coluimns 2 through 12 would be blank.
>
> According to you, I would need 12 tables.
>

Nope.  But you're too stoopid to understand that.


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

[toc] | [prev] | [next] | [standalone]

#12480

richard the sto0pid wrote:

> Suppose I had a table that had 12 columns and 365 rows. Which would
> represent a calendar.

One row for every day; I suppose that could be some form of "calendar" - 
albeit a strange one. What will you do for Leap Year? Why do you need 11 
extra fields?

> What data would be in the cell for Feb, 31?

Database tables have fields, not cells. A database is not a spreadsheet. 
There is no Feb 31.

> There would be data only in the cells for that given column.

That sentence is untranslatable.

> row1 would be Jan 1, column 1.
> row1 coluimns 2 through 12 would be blank.

What would you want to place in 11 extra *fields* for each day?

> According to you, I would need 12 tables.

Nothing of the sort, just another untranslatable statement. It enforces 
the fact that you know absolutely nothing about database design, 
especially _relational_ database design. You continue to reinforce Denis's 
statement of your "comprehension of computer systems which appears to have 
started at nothing and continues to devolve backwards."

While you're reading about Third Normal Form, also study Primary Keys and 
Foreign Keys.

-- 
   -bts
   -This space for rent, but the price is high

[toc] | [prev] | [next] | [standalone]

#12481

On Tue, 31 Dec 2013 21:08:20 -0500, richard wrote:

> Suppose I had a table that had 12 columns and 365 rows.
> Which would represent a calendar.

That's not how you'd represent a calendar in a database. You'd represent 
a calendar as:

start time, end time (or duration), event id

In the events table, you'd have more info about the event keyed by the 
event id, which might in turn link to other tables like contacts (for 
people attending the event) by way of link tables (contact id, event id) 
and locations (keyed by location id) for where the events are held.

The whole idea of relational databases is that the key information about 
each contact, event or location is only held in one table in one place, 
so eg if a contact happens to be an event attendee but also a location 
manager, the same contact id is used in the attendee link table and in 
the location table. Then if the contact changes their phone number, 
instead of having to change that phone number in the attendee list for 
every event the contact is attending and in the location table as the 
location manager, you only need to change it in the contact table, one 
change.

Not sure why I'm bothering to explain this. You seem to be genetically 
incapable of absorbing and comprehending database theory.

There's all these people designing working databases all over the planet 
using standard database theory, not to mention all the professors and 
undergrads and PhDs etc that study, develop and teach those theories, and 
then there's the richard methodology which seems to completely disagree 
with what everyone else is doing and teaching and researching.

And richard continues to insist that he is right and the rest of the 
world is wrong.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#12484

Am 01.01.2014 01:19, schrieb richard:

> On Tue, 31 Dec 2013 23:00:32 +0000 (UTC), Denis McMahon wrote:
> 
[...]
>> Here's one example of why Adriennes approach is easier:
>>
>> Supposing Adrienne decides to rename one of the three classifications. In 
>> Adriennes database, that involves a single sql operation on one row in 
>> one table. In your hypothetical and seriously fucked up database design, 
>> you would need to test each row in the whole database to see if the 
>> category was the one that needed to be changed, and then change it. Such 
>> a process is highly inefficient in terms of both cpu effort, memory 
>> management and disk io, and it is to prevent such inefficiencies amongst 
>> other things that relational database design theory has evolved to where 
>> it is today.
>>
>> Unlike your comprehension of computer systems which appears to have 
>> started at nothing and continues to devolve backwards.
> 
> I was merely suggesting one possible way.
> I have never liked the idea of making two tables where one is sufficient.

One table is NOT SUFFICIENT!

Because then EVERY classification has to be repeated over and over again
in every single record.

> In the OP's example, we have going on exactly what you speak of.

No we don't!

> Let's say he wants to add on a second pet shop
> Now he has to change the id's in two tables.

No! "Store" is a CATEGORY and "pet shop" is just an entry. One would
just create a record "Pet shop 2" with the CATEGORY "Store".

> Plus, the remaining id's all have to be changed accordingly.
> So what if he has 1,000 rows?

Even if the CATEGORY of existing entries would have to be changed - this
would be a simple SQL statement.

> He made a change on row 5. So now the sequence of events has to change
> 1990+ items?

No. You don't understand - as usual :-(



-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#12495

On 12/31/2013 07:19 PM, richard wrote:
> On Tue, 31 Dec 2013 23:00:32 +0000 (UTC), Denis McMahon wrote:
>
>> On Tue, 31 Dec 2013 17:06:38 -0500, richard wrote:
>>
>>> On Tue, 31 Dec 2013 21:08:42 +0000 (UTC), Adrienne Boswell wrote:
>>
>>>> I have a table that has three classifications.
>>
>>>> I have another table that has categories in each classification.
>>
>>> Why not have one table?
>>
>> Richard, you've proved time and time again that you have no understanding
>> of relational database design theory. Please stop trying to suggest that
>> people with sensibly designed databases should do it the stoopid way.
>>
>> Adrienne's query joins the multiple tables into a single dataset and
>> sorts the dataset, the question asked was how to process that sorted
>> dataset in a specific manner. The question has nothing to do with the
>> structure of the data in the database, the answer lies solely in how the
>> result object returned by the mysql[i]->query() is processed.
>>
>> Here's one example of why Adriennes approach is easier:
>>
>> Supposing Adrienne decides to rename one of the three classifications. In
>> Adriennes database, that involves a single sql operation on one row in
>> one table. In your hypothetical and seriously fucked up database design,
>> you would need to test each row in the whole database to see if the
>> category was the one that needed to be changed, and then change it. Such
>> a process is highly inefficient in terms of both cpu effort, memory
>> management and disk io, and it is to prevent such inefficiencies amongst
>> other things that relational database design theory has evolved to where
>> it is today.
>>
>> Unlike your comprehension of computer systems which appears to have
>> started at nothing and continues to devolve backwards.
>
> I was merely suggesting one possible way.
> I have never liked the idea of making two tables where one is sufficient.
>
> In the OP's example, we have going on exactly what you speak of.
> Let's say he wants to add on a second pet shop
> Now he has to change the id's in two tables.
> Plus, the remaining id's all have to be changed accordingly.
> So what if he has 1,000 rows?
> He made a change on row 5. So now the sequence of events has to change
> 1990+ items?
>
> In my example, if you want to add on another pet store, all you do is
> insert the new row and increment the id's.
>
> Otherwise, he should have a table for each category.
> Forget cross referencing with id's.
>

   The whole idea behind relational databases is to set things up so 
that you don't need to make changes like that.

-- 
Norman
Registered Linux user #461062
-Have you been to www.php.net yet?-

[toc] | [prev] | [next] | [standalone]

#12497

On Thu, 02 Jan 2014 06:23:23 -0500, Norman Peelman wrote:

> The whole idea behind relational databases is to set things up so
> that you don't need to make changes like that.

Norman, remember that richard is the guy that sets up a separate table 
for each year's records because that's more sensible (in richard land[1]) 
than having a year field in the record table.

[1] Any semblance of richard land to cloud cuckoo land is probably not 
coincidental.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#12498

On Thu, 2 Jan 2014 13:09:10 +0000 (UTC), Denis McMahon wrote:
> On Thu, 02 Jan 2014 06:23:23 -0500, Norman Peelman wrote:
>
>> The whole idea behind relational databases is to set things up so
>> that you don't need to make changes like that.
>
> Norman, remember that richard is the guy that sets up a separate table 
> for each year's records because that's more sensible (in richard land[1]) 
> than having a year field in the record table.
>
> [1] Any semblance of richard land to cloud cuckoo land is probably not 
> coincidental.

I think there was something about that helping to manage the size of the
tables as well. Because any database will break if you put more than a
couple thousand rows into a table...

-- 
It seems that we were audited recently, and the auditors found a certain
'f' word in the comments of a configuration file, and deemed that this
is a 'security risk'.
              -- Paul Fenwick

[toc] | [prev] | [next] | [standalone]

#12499

Peter H. Coffin wrote:

> Denis McMahon wrote:
>> Norman Peelman wrote:
>>> The whole idea behind relational databases is to set things up so that
>>> you don't need to make changes like that.
>>
>> Norman, remember that richard is the guy that sets up a separate table
>> for each year's records because that's more sensible (in richard
>> land[1]) than having a year field in the record table.
>>
>> [1] Any semblance of richard land to cloud cuckoo land is probably not
>> coincidental.
> 
> I think there was something about that helping to manage the size of the
> tables as well. Because any database will break if you put more than a
> couple thousand rows into a table...

Peter, please don't recommend the place you found that information as any 
kind of reputable reference site. I've worked with databases that had 
literally millions of records in single tables.

If your "database" consists of an Excel spreadsheet, you may have a minor 
point.

-- 
   -bts
   -This space for rent, but the price is high

[toc] | [prev] | [next] | [standalone]

#12500

On 1/2/2014 10:39 AM, Beauregard T. Shagnasty wrote:
> Peter H. Coffin wrote:
>
>> Denis McMahon wrote:
>>> Norman Peelman wrote:
>>>> The whole idea behind relational databases is to set things up so that
>>>> you don't need to make changes like that.
>>>
>>> Norman, remember that richard is the guy that sets up a separate table
>>> for each year's records because that's more sensible (in richard
>>> land[1]) than having a year field in the record table.
>>>
>>> [1] Any semblance of richard land to cloud cuckoo land is probably not
>>> coincidental.
>>
>> I think there was something about that helping to manage the size of the
>> tables as well. Because any database will break if you put more than a
>> couple thousand rows into a table...
>
> Peter, please don't recommend the place you found that information as any
> kind of reputable reference site. I've worked with databases that had
> literally millions of records in single tables.
>
> If your "database" consists of an Excel spreadsheet, you may have a minor
> point.
>

I may be wrong - but I think he meant that was another richardism.

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

[toc] | [prev] | [next] | [standalone]

#12502

Jerry Stuckle wrote:

> I may be wrong - but I think he meant that was another richardism.

Oh yeah ... I can see that now. Makes sense, too.   ;-)

-- 
   -bts
   -This space for rent, but the price is high

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.php

csiph-web