Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #14700 > unrolled thread

multiple open handles to mysql? (loops: fetches within fetches)

Back to article view | Back to comp.lang.php

Contents

  multiple open handles to mysql? (loops: fetches within fetches) oldyork90@yahoo.com - 2014-12-10 21:25 -0800
    Re: multiple open handles to mysql? (loops: fetches within fetches) Jerry Stuckle <jstucklex@attglobal.net> - 2014-12-11 22:45 -0500
      Re: multiple open handles to mysql? (loops: fetches within fetches) "J.O. Aho" <user@example.net> - 2014-12-12 07:51 +0100
        Re: multiple open handles to mysql? (loops: fetches within fetches) Jerry Stuckle <jstucklex@attglobal.net> - 2014-12-12 09:59 -0500
    Re: multiple open handles to mysql? (loops: fetches within fetches) oldyork90@yahoo.com - 2014-12-14 14:49 -0800
      Re: multiple open handles to mysql? (loops: fetches within fetches) Jerry Stuckle <jstucklex@attglobal.net> - 2014-12-14 19:49 -0500
    Re: multiple open handles to mysql? (loops: fetches within fetches) Richard Damon <Richard@Damon-Family.org> - 2014-12-14 21:54 -0500
      Re: multiple open handles to mysql? (loops: fetches within fetches) Jerry Stuckle <jstucklex@attglobal.net> - 2014-12-14 22:47 -0500
        Re: multiple open handles to mysql? (loops: fetches within fetches) Richard Damon <Richard@Damon-Family.org> - 2014-12-14 23:24 -0500
          Re: multiple open handles to mysql? (loops: fetches within fetches) Jerry Stuckle <jstucklex@attglobal.net> - 2014-12-14 23:57 -0500
            Re: multiple open handles to mysql? (loops: fetches within fetches) Richard Damon <Richard@Damon-Family.org> - 2014-12-19 08:50 -0500
              Re: multiple open handles to mysql? (loops: fetches within fetches) Jerry Stuckle <jstucklex@attglobal.net> - 2014-12-19 11:07 -0500
                Re: multiple open handles to mysql? (loops: fetches within fetches) Richard Damon <Richard@Damon-Family.org> - 2014-12-20 14:51 -0500
                  Re: multiple open handles to mysql? (loops: fetches within fetches) Jerry Stuckle <jstucklex@attglobal.net> - 2014-12-20 15:50 -0500

#14700 — multiple open handles to mysql? (loops: fetches within fetches)

$sth01 blah blah ... bind vars
$sth02 (same)

while ($seth01->fetch())
   while ($seth02->fetch())

I'm having difficulty building this with mysql 5.5 and php(mysqli).  
In an other language/database I can have
open and nested active fetches as above.

If this is not possible then how is it done?  Do you buffer the whole result, close, and reuse the handle?

Thanks - rookie

[toc] | [next] | [standalone]

#14701

On 12/11/2014 12:25 AM, oldyork90@yahoo.com wrote:
> 
> $sth01 blah blah ... bind vars
> $sth02 (same)
> 
> while ($seth01->fetch())
>    while ($seth02->fetch())
> 
> I'm having difficulty building this with mysql 5.5 and php(mysqli).  
> In an other language/database I can have
> open and nested active fetches as above.
> 
> If this is not possible then how is it done?  Do you buffer the whole result, close, and reuse the handle?
> 
> Thanks - rookie
> 

The real question here is - why do you think you need to do this?  And
your logic is flawed.

Even if you did get two different result sets, the first time through
the loop $seth02 will be emptied and all future requests will return
false.  The same thing will occur in any language (and any database).

I think a better solution would be to create the appropriate SQL to
return the results you want in one request.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14702

On 12/12/14 04:45, Jerry Stuckle wrote:
> On 12/11/2014 12:25 AM, oldyork90@yahoo.com wrote:
>>
>> $sth01 blah blah ... bind vars
>> $sth02 (same)
>>
>> while ($seth01->fetch())
>>     while ($seth02->fetch())
>>
>> I'm having difficulty building this with mysql 5.5 and php(mysqli).
>> In an other language/database I can have
>> open and nested active fetches as above.
>>
>> If this is not possible then how is it done?  Do you buffer the whole result, close, and reuse the handle?
>>
>> Thanks - rookie
>>
>
> The real question here is - why do you think you need to do this?  And
> your logic is flawed.
>
> Even if you did get two different result sets, the first time through
> the loop $seth02 will be emptied and all future requests will return
> false.  The same thing will occur in any language (and any database).
>
> I think a better solution would be to create the appropriate SQL to
> return the results you want in one request.
>

Just looking at the OP, I would guess the needed change to the query 
would be a JOIN and ORDER BY, as I would guess on that the first query 
fetches data from a group table and the second fetches those items which 
belongs to the group table.

Maybe better option for the OP to ask question about the query itself at 
comp.databases.mysql

-- 

  //Aho

[toc] | [prev] | [next] | [standalone]

#14704

On 12/12/2014 1:51 AM, J.O. Aho wrote:
> On 12/12/14 04:45, Jerry Stuckle wrote:
>> On 12/11/2014 12:25 AM, oldyork90@yahoo.com wrote:
>>>
>>> $sth01 blah blah ... bind vars
>>> $sth02 (same)
>>>
>>> while ($seth01->fetch())
>>>     while ($seth02->fetch())
>>>
>>> I'm having difficulty building this with mysql 5.5 and php(mysqli).
>>> In an other language/database I can have
>>> open and nested active fetches as above.
>>>
>>> If this is not possible then how is it done?  Do you buffer the whole
>>> result, close, and reuse the handle?
>>>
>>> Thanks - rookie
>>>
>>
>> The real question here is - why do you think you need to do this?  And
>> your logic is flawed.
>>
>> Even if you did get two different result sets, the first time through
>> the loop $seth02 will be emptied and all future requests will return
>> false.  The same thing will occur in any language (and any database).
>>
>> I think a better solution would be to create the appropriate SQL to
>> return the results you want in one request.
>>
> 
> Just looking at the OP, I would guess the needed change to the query
> would be a JOIN and ORDER BY, as I would guess on that the first query
> fetches data from a group table and the second fetches those items which
> belongs to the group table.
> 
> Maybe better option for the OP to ask question about the query itself at
> comp.databases.mysql
> 

Totally agree, J.O.  Of course, if the OP wants to display members by
group, that brings up a different problem - but one which can easily be
solved in PHP.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14706

Thank you all for the information.  I surrender, I'm not designing properly, but the question remains as it.  Thanks again.

[toc] | [prev] | [next] | [standalone]

#14707

On 12/14/2014 5:49 PM, oldyork90@yahoo.com wrote:
> Thank you all for the information.  I surrender, I'm not designing properly, but the question remains as it.  Thanks again.
> 

As J.O. said - you build your query properly, using the appropriate JOIN
syntax.

But since we don't know what you're trying to do, we can't help you any
further.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14708

On 12/11/14, 12:25 AM, oldyork90@yahoo.com wrote:
>
> $sth01 blah blah ... bind vars
> $sth02 (same)
>
> while ($seth01->fetch())
>     while ($seth02->fetch())
>
> I'm having difficulty building this with mysql 5.5 and php(mysqli).
> In an other language/database I can have
> open and nested active fetches as above.
>
> If this is not possible then how is it done?  Do you buffer the whole result, close, and reuse the handle?
>
> Thanks - rookie
>

I have used successfully something like

$seth01 = ...
while($row1 = $seth01->fetch()) {
   $seth02 = ... /* Build a 2nd query based on the results */
   while($row2 = $seth02->fetch()) {
     /* ... */
   }
}

[toc] | [prev] | [next] | [standalone]

#14709

On 12/14/2014 9:54 PM, Richard Damon wrote:
> On 12/11/14, 12:25 AM, oldyork90@yahoo.com wrote:
>>
>> $sth01 blah blah ... bind vars
>> $sth02 (same)
>>
>> while ($seth01->fetch())
>>     while ($seth02->fetch())
>>
>> I'm having difficulty building this with mysql 5.5 and php(mysqli).
>> In an other language/database I can have
>> open and nested active fetches as above.
>>
>> If this is not possible then how is it done?  Do you buffer the whole
>> result, close, and reuse the handle?
>>
>> Thanks - rookie
>>
> 
> I have used successfully something like
> 
> $seth01 = ...
> while($row1 = $seth01->fetch()) {
>   $seth02 = ... /* Build a 2nd query based on the results */
>   while($row2 = $seth02->fetch()) {
>     /* ... */
>   }
> }
> 
> 

Which could mean a lot of calls to MySQL, causing a lot of overhead.
Couldn't you have returned everything in one call to MySQL by using the
appropriate JOINs?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14710

On 12/14/14, 10:47 PM, Jerry Stuckle wrote:
> On 12/14/2014 9:54 PM, Richard Damon wrote:
>>
>> I have used successfully something like
>>
>> $seth01 = ...
>> while($row1 = $seth01->fetch()) {
>>    $seth02 = ... /* Build a 2nd query based on the results */
>>    while($row2 = $seth02->fetch()) {
>>      /* ... */
>>    }
>> }
>>
>>
>
> Which could mean a lot of calls to MySQL, causing a lot of overhead.
> Couldn't you have returned everything in one call to MySQL by using the
> appropriate JOINs?
>

In my case the second query is to a different database, so a JOIN 
wouldn't work.

It is also possible that the relationship between the queries is too 
complicated to express in SQL (for example, you need to deserialize a 
value to get part of the second query.

Also, in my case each query only generated a few results, so it wasn't 
worth spending time to optimize things.

[toc] | [prev] | [next] | [standalone]

#14711

On 12/14/2014 11:24 PM, Richard Damon wrote:
> On 12/14/14, 10:47 PM, Jerry Stuckle wrote:
>> On 12/14/2014 9:54 PM, Richard Damon wrote:
>>>
>>> I have used successfully something like
>>>
>>> $seth01 = ...
>>> while($row1 = $seth01->fetch()) {
>>>    $seth02 = ... /* Build a 2nd query based on the results */
>>>    while($row2 = $seth02->fetch()) {
>>>      /* ... */
>>>    }
>>> }
>>>
>>>
>>
>> Which could mean a lot of calls to MySQL, causing a lot of overhead.
>> Couldn't you have returned everything in one call to MySQL by using the
>> appropriate JOINs?
>>
> 
> In my case the second query is to a different database, so a JOIN
> wouldn't work.
>

Depending on the database, it might - MySQL will do it, for instance.

> It is also possible that the relationship between the queries is too
> complicated to express in SQL (for example, you need to deserialize a
> value to get part of the second query.
> 

Ah, then you've got a database design problem.  It fails first normal
form because you have more than one value in a row/column (a serialized
field).

> Also, in my case each query only generated a few results, so it wasn't
> worth spending time to optimize things.

That's good for now, but what about later?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14775

On 12/14/14, 11:57 PM, Jerry Stuckle wrote:
> On 12/14/2014 11:24 PM, Richard Damon wrote:
>> On 12/14/14, 10:47 PM, Jerry Stuckle wrote:
>>> On 12/14/2014 9:54 PM, Richard Damon wrote:
>>>>
>>>> I have used successfully something like
>>>>
>>>> $seth01 = ...
>>>> while($row1 = $seth01->fetch()) {
>>>>     $seth02 = ... /* Build a 2nd query based on the results */
>>>>     while($row2 = $seth02->fetch()) {
>>>>       /* ... */
>>>>     }
>>>> }
>>>>
>>>>
>>>
>>> Which could mean a lot of calls to MySQL, causing a lot of overhead.
>>> Couldn't you have returned everything in one call to MySQL by using the
>>> appropriate JOINs?
>>>
>>
>> In my case the second query is to a different database, so a JOIN
>> wouldn't work.
>>
>
> Depending on the database, it might - MySQL will do it, for instance.

Even if they use different credentials to access (and physically on 
different servers)?

>
>> It is also possible that the relationship between the queries is too
>> complicated to express in SQL (for example, you need to deserialize a
>> value to get part of the second query.
>>
>
> Ah, then you've got a database design problem.  It fails first normal
> form because you have more than one value in a row/column (a serialized
> field).

Sometimes getting something to "work" is more important than to by 
"correct" by some theoretical standard. Some things get very hard to 
"properly" normalize, and if you did, you make your normal access 
unnecessarily slow.

For example, how would you reasonably normalize a database where the 
"value" of a field is a polymorphic object (that implements some 
interface), whose type might not be know when you write your code?

>
>> Also, in my case each query only generated a few results, so it wasn't
>> worth spending time to optimize things.
>
> That's good for now, but what about later?
>

Sounds like you are advocating premature optimization. Sometimes adding 
a feature means doing thing in non-ideal manners, to avoid the need of 
an extensive re-write now. Yes, at some point later it might end up 
being required, but at that point the needs might be different so the 
rewrite would be different than if I did it now.

If I did something like this in a new design, there might be more 
justification of a complaint.

[toc] | [prev] | [next] | [standalone]

#14777

On 12/19/2014 8:50 AM, Richard Damon wrote:
> On 12/14/14, 11:57 PM, Jerry Stuckle wrote:
>> On 12/14/2014 11:24 PM, Richard Damon wrote:
>>> On 12/14/14, 10:47 PM, Jerry Stuckle wrote:
>>>> On 12/14/2014 9:54 PM, Richard Damon wrote:
>>>>>
>>>>> I have used successfully something like
>>>>>
>>>>> $seth01 = ...
>>>>> while($row1 = $seth01->fetch()) {
>>>>>     $seth02 = ... /* Build a 2nd query based on the results */
>>>>>     while($row2 = $seth02->fetch()) {
>>>>>       /* ... */
>>>>>     }
>>>>> }
>>>>>
>>>>>
>>>>
>>>> Which could mean a lot of calls to MySQL, causing a lot of overhead.
>>>> Couldn't you have returned everything in one call to MySQL by using the
>>>> appropriate JOINs?
>>>>
>>>
>>> In my case the second query is to a different database, so a JOIN
>>> wouldn't work.
>>>
>>
>> Depending on the database, it might - MySQL will do it, for instance.
> 
> Even if they use different credentials to access (and physically on
> different servers)?
>

No, but there is no indication that is the case here.

>>
>>> It is also possible that the relationship between the queries is too
>>> complicated to express in SQL (for example, you need to deserialize a
>>> value to get part of the second query.
>>>
>>
>> Ah, then you've got a database design problem.  It fails first normal
>> form because you have more than one value in a row/column (a serialized
>> field).
> 
> Sometimes getting something to "work" is more important than to by
> "correct" by some theoretical standard. Some things get very hard to
> "properly" normalize, and if you did, you make your normal access
> unnecessarily slow.
>

Just "getting it to work" instead of following well-respected standards
is a sign of laziness and/or ignorance.  And very seldom have I ever had
to denormalize below 3rd normal form.  Yes, occasionally I have had to
drop some tables down to 2nd normal form - but that was mainly due to
shortcomings in the RDBMS.  I haven't had to do this for years.

Of course, I also don't try to run gigabyte databases on MySQL.  I use a
real RDBMS.

> For example, how would you reasonably normalize a database where the
> "value" of a field is a polymorphic object (that implements some
> interface), whose type might not be know when you write your code?
> 

Database normalization is completely independent of code writing.  But
no, if you don't have the details required to create the database, how
can you create it?

And if you want an object in your database, you use an object oriented
RDBMS.


>>
>>> Also, in my case each query only generated a few results, so it wasn't
>>> worth spending time to optimize things.
>>
>> That's good for now, but what about later?
>>
> 
> Sounds like you are advocating premature optimization. Sometimes adding
> a feature means doing thing in non-ideal manners, to avoid the need of
> an extensive re-write now. Yes, at some point later it might end up
> being required, but at that point the needs might be different so the
> rewrite would be different than if I did it now.
> 
> If I did something like this in a new design, there might be more
> justification of a complaint.

Proper normalization is NEVER premature optimization.  It is PROPER DESIGN.

Not properly normalizing a database is just plain laziness and/or ignorance.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14782

On 12/19/14, 11:07 AM, Jerry Stuckle wrote:
> On 12/19/2014 8:50 AM, Richard Damon wrote:
>> On 12/14/14, 11:57 PM, Jerry Stuckle wrote:
>>> On 12/14/2014 11:24 PM, Richard Damon wrote:
>>>> On 12/14/14, 10:47 PM, Jerry Stuckle wrote:
>>>>> On 12/14/2014 9:54 PM, Richard Damon wrote:
>>>>>>
>>>>>> I have used successfully something like
>>>>>>
>>>>>> $seth01 = ...
>>>>>> while($row1 = $seth01->fetch()) {
>>>>>>      $seth02 = ... /* Build a 2nd query based on the results */
>>>>>>      while($row2 = $seth02->fetch()) {
>>>>>>        /* ... */
>>>>>>      }
>>>>>> }
>>>>>>
>>>>>>
>>>>>
>>>>> Which could mean a lot of calls to MySQL, causing a lot of overhead.
>>>>> Couldn't you have returned everything in one call to MySQL by using the
>>>>> appropriate JOINs?
>>>>>
>>>>
>>>> In my case the second query is to a different database, so a JOIN
>>>> wouldn't work.
>>>>
>>>
>>> Depending on the database, it might - MySQL will do it, for instance.
>>
>> Even if they use different credentials to access (and physically on
>> different servers)?
>>
>
> No, but there is no indication that is the case here.

You didn't ask! You were the one to say that I shouldn't do something 
the way it was done without knowing all the details.
>
>>>
>>>> It is also possible that the relationship between the queries is too
>>>> complicated to express in SQL (for example, you need to deserialize a
>>>> value to get part of the second query.
>>>>
>>>
>>> Ah, then you've got a database design problem.  It fails first normal
>>> form because you have more than one value in a row/column (a serialized
>>> field).
>>
>> Sometimes getting something to "work" is more important than to by
>> "correct" by some theoretical standard. Some things get very hard to
>> "properly" normalize, and if you did, you make your normal access
>> unnecessarily slow.
>>
>
> Just "getting it to work" instead of following well-respected standards
> is a sign of laziness and/or ignorance.  And very seldom have I ever had
> to denormalize below 3rd normal form.  Yes, occasionally I have had to
> drop some tables down to 2nd normal form - but that was mainly due to
> shortcomings in the RDBMS.  I haven't had to do this for years.
>
> Of course, I also don't try to run gigabyte databases on MySQL.  I use a
> real RDBMS.

Who said anything about gigabyte databases?

>
>> For example, how would you reasonably normalize a database where the
>> "value" of a field is a polymorphic object (that implements some
>> interface), whose type might not be know when you write your code?
>>
>
> Database normalization is completely independent of code writing.  But
> no, if you don't have the details required to create the database, how
> can you create it?

That was my question. You rejected the answer of writing a serialized 
version of the object.

>
> And if you want an object in your database, you use an object oriented
> RDBMS.
>

And what if you don't have a "object oriented RDBMS" (is there a 
commonly available, accessible in PHP, object oriented RDBMS?)
>
>>>
>>>> Also, in my case each query only generated a few results, so it wasn't
>>>> worth spending time to optimize things.
>>>
>>> That's good for now, but what about later?
>>>
>>
>> Sounds like you are advocating premature optimization. Sometimes adding
>> a feature means doing thing in non-ideal manners, to avoid the need of
>> an extensive re-write now. Yes, at some point later it might end up
>> being required, but at that point the needs might be different so the
>> rewrite would be different than if I did it now.
>>
>> If I did something like this in a new design, there might be more
>> justification of a complaint.
>
> Proper normalization is NEVER premature optimization.  It is PROPER DESIGN.
>
> Not properly normalizing a database is just plain laziness and/or ignorance.
>

So your answer to the task of generating a report which correlates some 
information between two WORKING and INDEPENDENT applications running on 
different machines is to re-write both of them to use a new schema (so 
you can normalize the combined schema) and put them on the same machine, 
and possibly change security rules by having them use common credentials 
(or at least be able to access data from the other application with its 
credentials)? Thank you for turning a small job into something massive.

Normalization is the "standard", and a good design principle, but not an 
absolute requirement (unless someone has imposed it as part of the 
problem statement). If it was, way aren't all your databases 6NF? There 
are conditions when denormalizing a database is reasonable, and even the 
best solution.

[toc] | [prev] | [next] | [standalone]

#14783

On 12/20/2014 2:51 PM, Richard Damon wrote:
> On 12/19/14, 11:07 AM, Jerry Stuckle wrote:
>> On 12/19/2014 8:50 AM, Richard Damon wrote:
>>> On 12/14/14, 11:57 PM, Jerry Stuckle wrote:
>>>> On 12/14/2014 11:24 PM, Richard Damon wrote:
>>>>> On 12/14/14, 10:47 PM, Jerry Stuckle wrote:
>>>>>> On 12/14/2014 9:54 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> I have used successfully something like
>>>>>>>
>>>>>>> $seth01 = ...
>>>>>>> while($row1 = $seth01->fetch()) {
>>>>>>>      $seth02 = ... /* Build a 2nd query based on the results */
>>>>>>>      while($row2 = $seth02->fetch()) {
>>>>>>>        /* ... */
>>>>>>>      }
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Which could mean a lot of calls to MySQL, causing a lot of overhead.
>>>>>> Couldn't you have returned everything in one call to MySQL by
>>>>>> using the
>>>>>> appropriate JOINs?
>>>>>>
>>>>>
>>>>> In my case the second query is to a different database, so a JOIN
>>>>> wouldn't work.
>>>>>
>>>>
>>>> Depending on the database, it might - MySQL will do it, for instance.
>>>
>>> Even if they use different credentials to access (and physically on
>>> different servers)?
>>>
>>
>> No, but there is no indication that is the case here.
> 
> You didn't ask! You were the one to say that I shouldn't do something
> the way it was done without knowing all the details.

No, and YOU DIDN'T ASK, EITHER, and have no indication that IS the case.

I answered according to the details provided - not some off the wall
possibility.

And BTW - if the data are actually related, they should be on the same
database.  And if they are on other servers, the OP should be using a
real database - one which allows access to databases on other servers.

>>
>>>>
>>>>> It is also possible that the relationship between the queries is too
>>>>> complicated to express in SQL (for example, you need to deserialize a
>>>>> value to get part of the second query.
>>>>>
>>>>
>>>> Ah, then you've got a database design problem.  It fails first normal
>>>> form because you have more than one value in a row/column (a serialized
>>>> field).
>>>
>>> Sometimes getting something to "work" is more important than to by
>>> "correct" by some theoretical standard. Some things get very hard to
>>> "properly" normalize, and if you did, you make your normal access
>>> unnecessarily slow.
>>>
>>
>> Just "getting it to work" instead of following well-respected standards
>> is a sign of laziness and/or ignorance.  And very seldom have I ever had
>> to denormalize below 3rd normal form.  Yes, occasionally I have had to
>> drop some tables down to 2nd normal form - but that was mainly due to
>> shortcomings in the RDBMS.  I haven't had to do this for years.
>>
>> Of course, I also don't try to run gigabyte databases on MySQL.  I use a
>> real RDBMS.
> 
> Who said anything about gigabyte databases?
>

I did.  But I also know that's just an excuse for you to make more trouble.

>>
>>> For example, how would you reasonably normalize a database where the
>>> "value" of a field is a polymorphic object (that implements some
>>> interface), whose type might not be know when you write your code?
>>>
>>
>> Database normalization is completely independent of code writing.  But
>> no, if you don't have the details required to create the database, how
>> can you create it?
> 
> That was my question. You rejected the answer of writing a serialized
> version of the object.
> 

That is true.  It violates first normal form,.  If you have an object,
use an object oriented database.

>>
>> And if you want an object in your database, you use an object oriented
>> RDBMS.
>>
> 
> And what if you don't have a "object oriented RDBMS" (is there a
> commonly available, accessible in PHP, object oriented RDBMS?)

Get one.  Use the right tool for the right job.  DB2, Oracle and SQL
Server all can emulate OO databases.  And all can be accessed from PHP.

>>
>>>>
>>>>> Also, in my case each query only generated a few results, so it wasn't
>>>>> worth spending time to optimize things.
>>>>
>>>> That's good for now, but what about later?
>>>>
>>>
>>> Sounds like you are advocating premature optimization. Sometimes adding
>>> a feature means doing thing in non-ideal manners, to avoid the need of
>>> an extensive re-write now. Yes, at some point later it might end up
>>> being required, but at that point the needs might be different so the
>>> rewrite would be different than if I did it now.
>>>
>>> If I did something like this in a new design, there might be more
>>> justification of a complaint.
>>
>> Proper normalization is NEVER premature optimization.  It is PROPER
>> DESIGN.
>>
>> Not properly normalizing a database is just plain laziness and/or
>> ignorance.
>>
> 
> So your answer to the task of generating a report which correlates some
> information between two WORKING and INDEPENDENT applications running on
> different machines is to re-write both of them to use a new schema (so
> you can normalize the combined schema) and put them on the same machine,
> and possibly change security rules by having them use common credentials
> (or at least be able to access data from the other application with its
> credentials)? Thank you for turning a small job into something massive.
> 
> Normalization is the "standard", and a good design principle, but not an
> absolute requirement (unless someone has imposed it as part of the
> problem statement). If it was, way aren't all your databases 6NF? There
> are conditions when denormalizing a database is reasonable, and even the
> best solution.

My answer is to properly design the database first.  There are good
reasons for proper normalization.  But you obviously don't understand
that.  But that also does not mean going all the way to 6NF.

But I know you're only trolling.  And database normalization is
off-topic in this newsgroup.  So I won't respond to you any longer.  You
can have the last word.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web