Path: csiph.com!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: ORMs comparisons/complaints. Date: Sat, 4 Jan 2014 19:51:58 +0000 (UTC) Organization: A noiseless patient Spider Lines: 76 Message-ID: References: <%JGtu.29103$Wm1.26832@fx17.iad> <52c4d306$0$302$14726298@news.sunsite.dk> <7LednV8eOcPXQVrPnZ2dnUVZ8gGdnZ2d@bt.com> <2NSdnfhiEq0J2VXPnZ2dnUVZ7q6dnZ2d@bt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Sat, 4 Jan 2014 19:51:58 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="e5160e2be48f1ea550cf61512446f525"; logging-data="15226"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/3mU9nlQ58VMNGx0FgKB8khJPIvdU5KRc=" User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Cancel-Lock: sha1:TxEVEfCRZz6CMm4FXN6Dl6In0TE= Xref: csiph.com comp.lang.java.programmer:27236 On Sat, 04 Jan 2014 17:27:45 +0000, lipska the kat wrote: > I've used MySQL in the past to throw together a prototype/proof of > concept. > Interesting: that is one I'd specifically avoid because it, along with Oracle, has/had some of the most nonstandard SQL syntax of any RDBMS. If I was doing it on a Windows box I'd consider using Watcom DB (SQL Anywhere) but otherwise I'd use either Postgres, which I like a lot, or Derby. > Agreed, but this is different from the inclusion of a field (whatever > that may be) who's only reason for being there is to provide a way to > relate records in a relational database. > OK, that sounds more like what I know as an SDBK (soft database key): an integer containing a unique value and used as a prime key that has no domain-specific meaning. Generally I agree with you and avoid their use. However, I will use them in about three specific circumstances: a)where the natural identifier is complex, such as in the aforementioned musical work where using the complex key would make SQL queries almost unreadable b)where the natural identifier is very long and can appear in several rows, e.g. an e-mail subject line or address. In this case I'd create an operational master containing two fields: the sdbk as prime key and the subject as a unique, indexed alternate key. The message table which, in straight normalisation, would normally hold the subject, would instead carry the operational master's PK. The prime reason for introducing such an operational master is data volume reduction. c)I'd do the same as in (b) to e-mail addresses for exactly the same reasons but would, in addition implement a M:M link to the message body, making the address use (To, From, CC) an attribute of the entity that implemented the M:M relationship, so that one join on the three tables can retrieve all the messages sent to and received from that address. > apparently don't see this as in any way intruding on the Object model, I > do, in fact I've even found myself using the RDBMS 'key' lurking in a > class as a key into a Map ... how crappy is that :-( > Exactly so. The sdbk in (a) would almost certainly need to be an attribute of the equivalent class. In case (b) the class would probably just carry the alternate key. The M:M entity in (c) would be quite unlikely to form a separate class: it and the OM would probably become array elements in a Message class. > I'm not being dogmatic here, it genuinely annoys the s*** out of me to > pollute my nice clean Object model with fields who's reason for > inclusion has nothing to do with the model. Maybe I need to get a life. > Agreed, except as I said above, where the set of fields forming the key is so long that the SQL becomes unreadable. FWIW, the musical works key is an actual example from a fully normalised database, though it was implemented using IDMS rather than an RDBMS, and we cheated a bit. We realised that most of the fields were empty in every actual work and so we could generate a CSV-type field by concatenating the field contents with '@' separators after conversion to upper case and use the resulting 60 character string as the PK. We also kept the original field contents as data so it could be displayed as input. Key generation from the field list was a cheap operation even in COBOL and searching on the resulting key was fast within an IDMS ordered indexed set. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |