> To get managers' quotas:
> SELECT Manager.name, quota FROM Manager, City
> WHERE Manager.serialNum=City.manager
>
> I take it that the "natural join" you refer to in some DBs
> eliminates the
> need for the WHERE clause in this case.
No, not in the above case. The natural join only assumes that columns
are related based on identical names. (Manager.serialNum =
City.serialNum)
A natural join would result in an illogical query where the manager is
joined to city based on having an identical serialnum column value.
This makes no sense.
Your example doesn't address the original problem at all since you don't
pull the serialNum's. My point is that by leaving them as ID's you have
made it easier to select and code around. I do not understand why
videoID() cannot exist in parallel with serialNum()? It seems to me
that you have the best of both worlds then. A method you can _always_
rely on and a column in the database that doesn't mess joins up.
Remember, MK supports most databases with minimal changes. The ability
to be "Natural Join Safe" is a very nice feature.
imagine
SELECT Manager.serialNum as ManagerID, City.serialNum as CityID
FROM Manager, City
WHERE Manager.serialNum = City.manager
instead of
SELECT ManagerID, CityID
FROM Manager, City
WHERE Manager.managerID = City.manager
You may not see much difference, but the 2nd is simpler
now imagine this
SELECT ManagerID, CityID
FROM Manager, City
(natural join on City.managerID and Manager.managerID)
Very easy IMHO.
--
Dave Rogers
Project Director / Sequoia Net.com
[EMAIL PROTECTED] / (517) 336-1090
> -----Original Message-----
> From: Chuck Esterbrook [mailto:[EMAIL PROTECTED]]
> Sent: Friday, June 29, 2001 1:28 PM
> To: Rogers, David
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Webware-discuss] MiddleKit Questions
>
>
> I CCed webware-discuss so this could be...discussed.
>
>
> At 10:18 AM 6/29/2001 -0400, Rogers, David wrote:
> >The reason why you should keep it videoID instead of serialnum is in
> >case people are doing joins on the tables. If you do a join and 2
> >columns have the same name a natural may be performed on
> them (I say may
> >because different db's act in different ways). Also, you
> will have to
> >refer to the completely qualified column name foobar.serialNum or
> >monkey.serialNum instead of foobarID and monkeyID if a
> natural join is
> >not performed. Can't he/we still use videoID()? I guess I
> never tried.
>
> No, the Python method is serialNum() and will remain so.
>
>
> >I know MK doesn't use joins but someone may need to write
> custom methods
> >to join certain tables and this makes it a lot easier. MK's run time
> >performance is one of its biggest flaws, don't make it worse
> by making
> >custom joins more difficult and confusing by having all
> tables share a
> >common column name.
>
> So you're worried that people would have to write the following?
>
> Given:
>
> Manager table
> serialNum int
> name varchar
> City table
> serialNum int
> name varchar
> manager int
>
> To get managers' quotas:
> SELECT Manager.name, quota FROM Manager, City
> WHERE Manager.serialNum=City.manager
>
> I take it that the "natural join" you refer to in some DBs
> eliminates the
> need for the WHERE clause in this case.
>
>
> -Chuck
>
>
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/webware-discuss
