Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #14777
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Newsgroups | comp.lang.php |
| Subject | Re: multiple open handles to mysql? (loops: fetches within fetches) |
| Date | 2014-12-19 11:07 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <m71if9$k3p$1@dont-email.me> (permalink) |
| References | (1 earlier) <o3sjw.910912$Rp.760133@fx23.iad> <m6lljb$5hd$1@dont-email.me> <Tntjw.876687$UR.712601@fx04.iad> <m6lpng$g9k$1@dont-email.me> <_2Wkw.833780$Ub6.438376@fx20.iad> |
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
==================
Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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