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

Groups > comp.lang.php > #14783

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

Show all headers | View raw

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
==================

Back to comp.lang.php | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

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

csiph-web