| Re: Loop through array, change headings [message #184439 is a reply to message #184438] |
Wed, 01 January 2014 00:39   |
Denis McMahon
Messages: 634
Registered: September 2010
Karma:
|
Senior Member |
|
|
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(at)gmail(dot)com
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]