| Re: Loop through array, change headings [message #184438 is a reply to message #184436] |
Wed, 01 January 2014 00:19   |
Mr Oldies
Messages: 241
Registered: October 2013
Karma:
|
Senior Member |
|
|
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.
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]