| Re: Loop through array, change headings [message #184444 is a reply to message #184443] |
Wed, 01 January 2014 02:43   |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 12/31/2013 9:08 PM, richard wrote:
> 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.
>
You don't even understand the question, RTS!
Here's a hint: In your design, if there were no restaurants, there would
be no restaurant category.
>
> 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?
>
You tell me. I wouldn't even try to design a database in such a stoopid
way.
> 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.
>
Nope. But you're too stoopid to understand that.
--
==================
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
]