| Re: Loop through array, change headings [message #184442 is a reply to message #184438] |
Wed, 01 January 2014 01:50   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]