RE: [edict-jmdict] mysql limitations

[Jim Breen <Jim.Breen@**********************>]

[Stuart McGraw (RE: [edict-jmdict] mysql limitations) writes:]
>> 
>> But just to be clear, the issue is not group_concat, but 
>> subqueries.  These are a standard part of sql, used in 
>> answering many kinds of questions.  

My reaction here is: "well what is the database for?".

I guess my (initial) idea/concept is that it is primarily for supporting
an online edit capability, combined with the periodic generation of the
distributed forms (JMdict, EDICT, etc.)

A secondary role is to enable a small nmber of gurus to do smart things at
the database command/browser level, although my conservatism tells me such
things are probably better done on another system, for the sake of 
integrity and performance. But yes, it would be great to be able to
do a bulk update according to some criteria.

>> I am not advocating using every shiny "gee-whiz" feature 
>> that the chosen database offers -- on the contrary I try to 
>> stick with standard sql where possible, and where not, to 
>> only use features that also can be implemented in other databases
>> albeit with some work.  But as I pointed out, subqueries are 
>> standard sql and short of doing the work in the application, 
>> it is difficult to work around their lack (whether that lack is
>> because they are missing, or because they are too inefficient
>> to use.)

I guess all other things being equal, having efficient subquery processing
is a Good Thing(TM), but if guru-level activity is going to be sparse,
performance with subqueries may not be a huge issue.

Jim

-- 
Jim Breen                                http://www.csse.monash.edu.au/~jwb/
Clayton School of Information Technology,               Tel: +61 3 9905 9554
Monash University, VIC 3800, Australia                  Fax: +61 3 9905 5146
(Monash Provider No. 00008C)                ジム・ブリーン@モナシュ大学