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