| Re: Loop through array, change headings [message #184462 is a reply to message #184438] |
Thu, 02 January 2014 11:23   |
Norman Peelman
Messages: 126
Registered: September 2010
Karma:
|
Senior Member |
|
|
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?-
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]