Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #27043 > unrolled thread
| Started by | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| First post | 2013-12-22 11:05 -0800 |
| Last post | 2014-01-03 15:43 -0500 |
| Articles | 20 on this page of 163 — 27 participants |
Back to article view | Back to comp.lang.java.programmer
ORMs comparisons/complaints. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-12-22 11:05 -0800
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-22 14:46 -0500
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-22 15:17 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-22 15:38 -0500
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-22 15:47 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-22 16:04 -0500
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-22 16:09 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-22 16:20 -0500
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-22 16:34 -0500
Re: ORMs comparisons/complaints. Christoph Michael Becker <cmbecker69@arcor.de> - 2013-12-22 22:45 +0100
Re: ORMs comparisons/complaints. markspace <markspace@nospam.nospam> - 2013-12-22 17:33 -0800
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-23 12:54 +1100
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-22 22:34 -0500
Re: ORMs comparisons/complaints. Wanja Gayk <brixomatic@yahoo.com> - 2013-12-24 12:28 +0100
c Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-24 08:49 -0500
Re: c "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-25 09:35 +1100
Re: c Graham Hobbs <ghobbs@cdpwise.net> - 2013-12-24 19:35 -0500
Re: c Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-25 00:08 -0500
Re: c lipska the kat <"lipskathekat at yahoo dot co dot uk"> - 2013-12-25 09:07 +0000
Re: c "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-25 20:41 +1100
[EOD] Re: c Wanja Gayk <brixomatic@yahoo.com> - 2013-12-25 11:15 +0100
Re: [EOD] Re: c "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-25 23:29 +1100
Re: [EOD] Re: c The Natural Philosopher <tnp@invalid.invalid> - 2013-12-25 12:48 +0000
Re: c "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-25 17:46 +1100
Re: c Graham Hobbs <ghobbs@cdpwise.net> - 2013-12-25 09:24 -0500
Re: c Arne Vajhøj <arne@vajhoej.dk> - 2013-12-29 22:51 -0500
Re: c Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-30 08:03 -0500
Re: c Arne Vajhøj <arne@vajhoej.dk> - 2013-12-30 12:40 -0500
Re: c Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-30 12:46 -0500
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-22 22:48 -0500
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-23 17:38 +1100
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-23 07:57 -0500
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-24 10:11 +1100
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-23 19:59 -0500
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-24 12:14 +1100
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-29 23:02 -0500
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-30 15:40 +1100
Re: ORMs comparisons/complaints. Michael Vilain <vilain@NOspamcop.net> - 2013-12-22 20:48 -0800
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-29 22:46 -0500
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-30 14:54 +1100
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-29 23:06 -0500
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-30 15:21 +1100
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-30 08:04 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-30 12:32 -0500
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-30 12:47 -0500
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2013-12-31 08:23 +1100
Re: ORMs comparisons/complaints. Doug Miller <doug_at_milmac_dot_com@example.com> - 2013-12-30 19:45 +0000
Re: ORMs comparisons/complaints. Ricardo Palomaes <rpmdisguise-java@nowhere.com> - 2013-12-30 19:20 +0100
Re: ORMs comparisons/complaints. The Natural Philosopher <tnp@invalid.invalid> - 2013-12-30 18:34 +0000
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-30 14:27 -0500
Re: ORMs comparisons/complaints. Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-12-22 22:26 +0100
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-29 23:17 -0500
Re: ORMs comparisons/complaints. Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-12-31 11:12 +0100
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-03 21:35 -0500
Re: ORMs comparisons/complaints. Marcel Müller <news.5.maazl@spamgourmet.org> - 2014-01-06 22:19 +0100
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-07 23:33 -0400
Re: ORMs comparisons/complaints. leif.roar@invalid.com (Leif Roar Moldskred) - 2014-01-08 00:37 -0600
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-30 17:03 -0400
Re: ORMs comparisons/complaints. Marcel Müller <news.5.maazl@spamgourmet.org> - 2013-12-31 15:30 +0100
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-02 03:57 -0400
Re: ORMs comparisons/complaints. Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-02 21:00 +0000
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 01:34 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-03 21:56 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-04 01:15 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-04 14:45 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-05 03:59 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-05 15:51 -0500
Re: ORMs comparisons/complaints. Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-05 23:53 +0000
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-05 20:00 -0500
Re: ORMs comparisons/complaints. "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-01-03 15:38 +0000
Re: ORMs comparisons/complaints. "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-01-03 15:41 +0000
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-03 12:27 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 18:49 -0400
Re: ORMs comparisons/complaints. "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-01-03 15:39 +0000
Re: ORMs comparisons/complaints. Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-12-22 16:11 -0800
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-29 23:08 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-30 17:36 -0400
Re: ORMs comparisons/complaints. The Natural Philosopher <tnp@invalid.invalid> - 2013-12-30 22:13 +0000
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-30 22:09 -0400
Re: ORMs comparisons/complaints. The Natural Philosopher <tnp@invalid.invalid> - 2013-12-31 11:30 +0000
Re: ORMs comparisons/complaints. Jerry Stuckle <jstucklex@attglobal.net> - 2013-12-31 08:11 -0500
Re: ORMs comparisons/complaints. "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-01-01 14:20 +0000
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-01 22:05 -0500
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2014-01-02 14:48 +1100
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-01 21:57 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-02 04:04 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-02 20:39 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 09:10 -0400
Re: ORMs comparisons/complaints. Lars Enderin <lars.enderin@telia.com> - 2014-01-03 20:10 +0100
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 18:34 -0400
Re: ORMs comparisons/complaints. Lars Enderin <lars.enderin@telia.com> - 2014-01-04 07:02 +0100
Re: ORMs comparisons/complaints. Joerg Meier <joergmmeier@arcor.de> - 2014-01-04 14:12 +0100
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-04 13:53 -0500
Re: ORMs comparisons/complaints. Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2014-01-08 11:48 +0200
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-08 14:27 -0400
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-04 17:17 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-01 21:54 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-02 04:09 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-02 20:54 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 09:18 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-03 16:45 -0500
Re: ORMs comparisons/complaints. Silvio <silvio@internet.com> - 2013-12-23 13:25 +0100
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-29 23:27 -0500
Re: ORMs comparisons/complaints. Silvio <silvio@internet.com> - 2013-12-30 14:38 +0100
Re: ORMs comparisons/complaints. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-12-30 09:36 -0800
Re: ORMs comparisons/complaints. Silvio <silvio@internet.com> - 2013-12-31 01:26 +0100
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-01 22:23 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-01 22:19 -0500
Re: ORMs comparisons/complaints. Silvio <silvio@internet.com> - 2014-01-02 12:36 +0100
Re: ORMs comparisons/complaints. Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2014-01-02 09:36 -0800
Re: ORMs comparisons/complaints. Silvio <silvio@internet.com> - 2014-01-02 21:06 +0100
Re: ORMs comparisons/complaints. "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-01-03 14:48 +0000
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-02 20:59 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-02 21:07 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-02 21:10 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-31 09:44 -0400
Re: ORMs comparisons/complaints. leif.roar@invalid.com (Leif Roar Moldskred) - 2013-12-23 07:22 -0600
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2013-12-29 23:20 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-25 13:56 -0400
Re: ORMs comparisons/complaints. jebblue <n@n.nnn> - 2013-12-31 10:52 -0600
Re: ORMs comparisons/complaints. Evan Platt <evan@theobvious.espphotography.com.invalid> - 2013-12-31 11:50 -0800
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-12-31 17:54 -0400
Re: ORMs comparisons/complaints. jebblue <n@n.nnn> - 2013-12-31 19:33 -0600
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-02 17:37 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-01 21:46 -0500
Re: ORMs comparisons/complaints. Gordon Levi <gordon@address.invalid> - 2014-01-02 19:34 +1100
Re: ORMs comparisons/complaints. lipska the kat <lipskathekat@example.com> - 2014-01-02 10:02 +0000
Re: ORMs comparisons/complaints. "Qu0ll" <Qu0llSixFour@gmail.com> - 2014-01-02 23:09 +1100
Re: ORMs comparisons/complaints. lipska the kat <lipskathekat@example.com> - 2014-01-02 12:22 +0000
Re: ORMs comparisons/complaints. Gordon Levi <gordon@address.invalid> - 2014-01-03 20:06 +1100
Re: ORMs comparisons/complaints. lipska the kat <lipskathekat@example.com> - 2014-01-03 09:17 +0000
Re: ORMs comparisons/complaints. Gordon Levi <gordon@address.invalid> - 2014-01-04 00:41 +1100
Re: ORMs comparisons/complaints. leif.roar@invalid.com (Leif Roar Moldskred) - 2014-01-03 06:41 -0600
Re: ORMs comparisons/complaints. "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-01-03 14:56 +0000
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 12:12 -0400
Re: ORMs comparisons/complaints. Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-03 19:30 +0000
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 16:04 -0400
Re: ORMs comparisons/complaints. Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-03 22:30 +0000
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-05 23:44 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-03 16:28 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-03 16:08 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 16:22 -0400
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 00:29 -0400
Re: ORMs comparisons/complaints. lipska the kat <lipskathekat@example.com> - 2014-01-03 09:08 +0000
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 10:18 -0400
Re: ORMs comparisons/complaints. lipska the kat <lipskathekat@example.com> - 2014-01-03 15:24 +0000
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 17:10 -0400
Re: ORMs comparisons/complaints. lipska the kat <lipskathekat@example.com> - 2014-01-04 10:02 +0000
Re: ORMs comparisons/complaints. Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-04 16:02 +0000
Re: ORMs comparisons/complaints. lipska the kat <lipskathekat@example.com> - 2014-01-04 17:27 +0000
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-04 12:46 -0500
Re: ORMs comparisons/complaints. Martin Gregorie <martin@address-in-sig.invalid> - 2014-01-04 19:51 +0000
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-04 19:24 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-04 14:08 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-03 16:39 -0500
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-02 20:43 -0500
Re: ORMs comparisons/complaints. Gordon Levi <gordon@address.invalid> - 2014-01-03 20:19 +1100
Re: ORMs comparisons/complaints. lipska the kat <lipskathekat@example.com> - 2014-01-03 09:23 +0000
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 11:34 -0400
Re: ORMs comparisons/complaints. lipska the kat <lipskathekat@example.com> - 2014-01-03 15:58 +0000
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-03 16:01 -0500
Re: ORMs comparisons/complaints. Arved Sandstrom <asandstrom2@eastlink.ca> - 2014-01-03 17:44 -0400
Re: ORMs comparisons/complaints. Arne Vajhøj <arne@vajhoej.dk> - 2014-01-03 15:43 -0500
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2014-01-02 21:00 +0000 |
| Message-ID | <la4k1e$sf8$1@dont-email.me> |
| In reply to | #27167 |
On Thu, 02 Jan 2014 03:57:27 -0400, Arved Sandstrom wrote: > Not entirely sure what you mean here, Marcel. In all seriousness I don't > think I've ever seen anyone normalize or selectively denormalize a data > model at "object level". Apart from that, I'm not quite sure how one > would conveniently normalize data at the object level (presumably > through the ORM) if the data showed up denormalized. > Does he mean near-exclusive use of 3NF? On the occasions when I've stopped at 2NF where the database or 4GL supports that and/or thrown a few derived fields such as account totals etc. into the data model. I've usually regretted it. I seldom find myself mapping data model entities 1:1 onto objects for two reasons: firstly, because after spending quite a bit of time as a DB designer/tuner/developer and writing a fair bit of SQL in the process I tend to think in terms of using JDBC rather than a JPA and partly because about the only times I've needed to handle arrays of objects that represent entities they've ended up as components of an object representing an ordered collection of the components, e.g. the collection of GPS fixes representing a flight path. In these cases, and individual component is of relatively little interest because you want to display or analyze the collection as a whole and/or its an intermediate data store used as part of transforming the collection from one external representation to another. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2014-01-03 01:34 -0400 |
| Message-ID | <NZrxu.144517$tR7.1505@fx22.iad> |
| In reply to | #27177 |
On 01/02/2014 05:00 PM, Martin Gregorie wrote: > On Thu, 02 Jan 2014 03:57:27 -0400, Arved Sandstrom wrote: > >> Not entirely sure what you mean here, Marcel. In all seriousness I don't >> think I've ever seen anyone normalize or selectively denormalize a data >> model at "object level". Apart from that, I'm not quite sure how one >> would conveniently normalize data at the object level (presumably >> through the ORM) if the data showed up denormalized. >> > Does he mean near-exclusive use of 3NF? > > On the occasions when I've stopped at 2NF where the database or 4GL > supports that and/or thrown a few derived fields such as account totals > etc. into the data model. I've usually regretted it. > > I seldom find myself mapping data model entities 1:1 onto objects for two > reasons: firstly, because after spending quite a bit of time as a DB > designer/tuner/developer and writing a fair bit of SQL in the process I > tend to think in terms of using JDBC rather than a JPA and partly because > about the only times I've needed to handle arrays of objects that > represent entities they've ended up as components of an object > representing an ordered collection of the components, e.g. the collection > of GPS fixes representing a flight path. In these cases, and individual > component is of relatively little interest because you want to display or > analyze the collection as a whole and/or its an intermediate data store > used as part of transforming the collection from one external > representation to another. > One of the sweetest things to me about JPA is constructor expressions. I actually have met a few of the guys who came up with this: if there is one concept in JPA that recognizes practical needs, and doesn't get too theoretical, it's this one. It's much better, IMO, than the plethora of other JPA techniques for producing objects. You're not the first person in this thread who referred to object collections or aggregate values. I've not myself found straight SQL or JDBC any better than JPA for doing this stuff: if your app is Java then you ultimately need to translate into objects, and often object collections. I don't care to continually write that boilerplate myself. AHS -- When a true genius appears, you can know him by this sign: that all the dunces are in a confederacy against him. -- Jonathan Swift
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2014-01-03 21:56 -0500 |
| Message-ID | <52c7786e$0$297$14726298@news.sunsite.dk> |
| In reply to | #27152 |
On 12/31/2013 9:30 AM, Marcel Müller wrote: > On 30.12.13 22.03, Arved Sandstrom wrote: >>> There is one advantage. Adding attributes to the data model is quite >>> simple with an ORM. No need to do redundant changes at many locations. >>> But any document DB will provide this as well without the need for SQL >>> and an ORM. >> >> By regarding your data as being document-oriented you already made a >> fundamental decision that your data is semi-structured or >> non-structured. > > Well, an XML is a document too, and most of the time it is well structured. It can be but does not need to be. If there is a schema defining the format and data get validated against it then it is well structured. That also carry some of the same restrictions as relational databases even though XML schemas allow for much more flexible structures than database tables. If there are no schema or validation then there are no structure enforced. > I do not really have experience with NoSQL databases. But I used non > relational data models and in memory computing now for about 6 years in > different projects. None of the projects failed, all are still live. > Also we did not really save resources because of the decisions made. But > from the code maintenance and from the performance point of view it was > successful. Some change requests to the first of these projects were > implemented by an apprentice in half an hour. This would have taken a > few days by a qualified programmer, if we had chosen a relational data > model. > > In the last project - a larger one - we have significant performance > benefits. There is an adjacent third party application with a very > similar data model from the customers point of view. (They are better > with respect to inheritance, we are better with respect to deep > structures but both can deal with polymorphism, table properties an so on.) > They ended up with solution d). We use XML documents. Measurements show > about three orders of magnitude performance difference, measured in time > per object access. We have two CPU cores with <30% load if users make > traffic. They have 16 CPU at 80-100% load if users make traffic. The > number of objects and attributes is comparable. In fact the data is > partially synchronized by interfaces. Both are Web applications. The > number of users is comparable. > OK, they have chosen PHP (used in an object oriented way), we have .NET > 3.5. But this will not explain all the 3 orders of magnitude. Their > system creates heavy load on the large attribute values table. There are plenty of cases where relational databases are not the best solution. Google, Facebook, Yahoo etc. did not go NoSQL just for fun. But I would still consider a relational database to be the default for persistence - what you use unless you have specific reasons not to. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2014-01-04 01:15 -0400 |
| Message-ID | <qNMxu.89339$wB.26683@fx28.iad> |
| In reply to | #27225 |
On 01/03/2014 10:56 PM, Arne Vajhøj wrote: [ SNIP ] > There are plenty of cases where relational databases are not the best > solution. > > Google, Facebook, Yahoo etc. did not go NoSQL just for fun. > > But I would still consider a relational database to be the default > for persistence - what you use unless you have specific reasons > not to. > > Arne > > Quite a few important companies (so probably many more minor companies) played with NoSQL for a bit, and then have backed off in various degrees. Nobody went for NoSQL just for fun...most went for it because they were sucked in by hype or misguided opinion. I'd estimate that the majority of people have returned to RDBMSs. The fact that a number of large companies have systems that are not relational is because you can't throw away a few tens or hundreds of millions of $$ in a few months or years. NoSQL is based on relaxing ACID, particularly consistency. You do that by cheating your end users through increasing UI speed, while at the same time decreasing the validity of your data. AHS -- When a true genius appears, you can know him by this sign: that all the dunces are in a confederacy against him. -- Jonathan Swift
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2014-01-04 14:45 -0500 |
| Message-ID | <52c864f6$0$298$14726298@news.sunsite.dk> |
| In reply to | #27226 |
On 1/4/2014 12:15 AM, Arved Sandstrom wrote: > On 01/03/2014 10:56 PM, Arne Vajhøj wrote: > [ SNIP ] > >> There are plenty of cases where relational databases are not the best >> solution. >> >> Google, Facebook, Yahoo etc. did not go NoSQL just for fun. >> >> But I would still consider a relational database to be the default >> for persistence - what you use unless you have specific reasons >> not to. > > Quite a few important companies (so probably many more minor companies) > played with NoSQL for a bit, and then have backed off in various > degrees. Nobody went for NoSQL just for fun...most went for it because > they were sucked in by hype or misguided opinion. I'd estimate that the > majority of people have returned to RDBMSs. The fact that a number of > large companies have systems that are not relational is because you > can't throw away a few tens or hundreds of millions of $$ in a few > months or years. > > NoSQL is based on relaxing ACID, particularly consistency. You do that > by cheating your end users through increasing UI speed, while at the > same time decreasing the validity of your data. There is a lot more to it than that. NoSQL is really many different things. There are some large distributed database systems. There are some which I would call modern replacements for traditional ISAM files. Some are AP. Some are CP. CouchDB and Neo4J are ACID. The big internet companies did not go to NoSQL due to the hype - as the hype was created by them going to NoSQL and they are not staying with NoSQL to avoid a large write off. They are went to and are staying with NoSQL, because the relational databases can not do the job. Relational databases and PB just does not work performance and cost wise. I am sure that there is a large portion of smaller companies that went NoSQL (typical something "ISAM like") that did so due to the hype. And I am sure that some of them regretted that they did so. But persistence is not a one size fit all. Different requirements can lead to different solutions. C is critical in many contexts (like money transactions). But there are other contexts where it does not matter (does it matter that Facebook users in Mexico sees an update 5 minutes later than the Facebook users in Finland? No!). There are quite a few of those C & ACID relational databases where for performance reasons the web apps in front actually cache and use data for N seconds even though the data may have been updated. In that case they are paying for C & ACID for no reason. All that said then I still consider relational the default choice. Especially for small startups. One get a lot of functionality and features that may be useful. If later a need for something with less functionality & features but higher performance for config shows up, then it can be valid to change. Or to put it another way: to me choosing NoSQL is an optimization and general rules about premature optimization applies. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2014-01-05 03:59 -0400 |
| Message-ID | <oh8yu.111237$Qi4.25124@fx11.iad> |
| In reply to | #27235 |
On 01/04/2014 03:45 PM, Arne Vajhøj wrote: > On 1/4/2014 12:15 AM, Arved Sandstrom wrote: >> On 01/03/2014 10:56 PM, Arne Vajhøj wrote: >> [ SNIP ] >> >>> There are plenty of cases where relational databases are not the best >>> solution. >>> >>> Google, Facebook, Yahoo etc. did not go NoSQL just for fun. >>> >>> But I would still consider a relational database to be the default >>> for persistence - what you use unless you have specific reasons >>> not to. >> >> Quite a few important companies (so probably many more minor companies) >> played with NoSQL for a bit, and then have backed off in various >> degrees. Nobody went for NoSQL just for fun...most went for it because >> they were sucked in by hype or misguided opinion. I'd estimate that the >> majority of people have returned to RDBMSs. The fact that a number of >> large companies have systems that are not relational is because you >> can't throw away a few tens or hundreds of millions of $$ in a few >> months or years. >> >> NoSQL is based on relaxing ACID, particularly consistency. You do that >> by cheating your end users through increasing UI speed, while at the >> same time decreasing the validity of your data. > > There is a lot more to it than that. > > NoSQL is really many different things. > There are some large distributed database systems. There are some > which I would call modern replacements for traditional ISAM files. > > Some are AP. Some are CP. CouchDB and Neo4J are ACID. Well, we know at least one thing, NoSQL is not SQL...by definition. :-) What we should really do is get rid of the term NoSQL, since it literally means "no SQL". We also have the problem that originally "NoSQL" did refer to non-relational data stores that relaxed ACID guarantees. Many, perhaps most, still do have relaxed guarantees. Some NoSQL systems are ACID, I agree with you, but sometimes you have to make the extra effort to obtain that functionality. I may date myself here. When people started producing "NoSQL" databases, it was a large part of the definition that ACID guarantees were relaxed. This is just historical fact. That some people started restoring ACID to NoSQL doesn't mean that relaxation of consistency isn't still often a key concept. > The big internet companies did not go to NoSQL due to the hype - as > the hype was created by them going to NoSQL and they are not staying > with NoSQL to avoid a large write off. They are went to and are > staying with NoSQL, because the relational databases can not do > the job. Relational databases and PB just does not work performance > and cost wise. I think we should definitely drop the "NoSQL" terminology here. SQL per se is irrelevant. I find it somewhat astonishing that in 2014, with literally dozens or hundreds or thousands of fast large-memory servers available to a company, that a performant solution can't be accomplished with relational. Eric Brewer's CAP theorem is a nice academic notion. What I've often wondered is why people jumped on ideas like that, most of which is certainly sound, and tossed the baby out with the dishwater. A whack of folks went wild on document databases - note that a document is frequently self-contained and quite relational. Other people went wild on re-inventing wheels differently: they totally abandoned relational DBs and figured they wouldn't work at all in highly distributed systems. Oddly enough, some of the "big internet companies" you allude to do in fact use relational DBs that are highly distributed. The access latency of such highly distributed RDBMSs is only marginally worse than the "Big Data" systems we now usually think of. It also happens that when companies do this, it's because they do in fact value relational feautures. > I am sure that there is a large portion of smaller companies that went > NoSQL (typical something "ISAM like") that did so due to the hype. And > I am sure that some of them regretted that they did so. A lot did, yes. I'm sure I mentioned before that about 15 years ago I worked for a company that proposed to do very innovative stuff with WML and HDML on cellphones. Probably the worst decision we ever made was to switch from Allaire Cold Fusion to J2EE. All due to hype. > But persistence is not a one size fit all. Different requirements can > lead to different solutions. > > C is critical in many contexts (like money transactions). But there are > other contexts where it does not matter (does it matter that Facebook > users in Mexico sees an update 5 minutes later than the Facebook users > in Finland? No!). That's not a great consistency or transactional example, Arne. No offense. It might be better to consider the problem of a *single individual* doing something. > There are quite a few of those C & ACID relational databases where > for performance reasons the web apps in front actually cache and > use data for N seconds even though the data may have been updated. In > that case they are paying for C & ACID for no reason. This is true. But let's be real: an ACID consistency guarantee means that your data may be a few seconds old but accurate. A non-ACID system often means your data is not accurate all the time. If you've got an ORM or web framework or HTTP server doing caching in front of an ACID database, you've still got the C in ACID: the information might just be a bit stale. > All that said then I still consider relational the default choice. > Especially for small startups. One get a lot of functionality and > features that may be useful. If later a need for something with > less functionality & features but higher performance for config > shows up, then it can be valid to change. > > Or to put it another way: to me choosing NoSQL is an optimization > and general rules about premature optimization applies. > > Arne > I agree with the above 2 paras. AHS -- When a true genius appears, you can know him by this sign: that all the dunces are in a confederacy against him. -- Jonathan Swift
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2014-01-05 15:51 -0500 |
| Message-ID | <52c9c5d4$0$302$14726298@news.sunsite.dk> |
| In reply to | #27241 |
On 1/5/2014 2:59 AM, Arved Sandstrom wrote: > On 01/04/2014 03:45 PM, Arne Vajhøj wrote: >> On 1/4/2014 12:15 AM, Arved Sandstrom wrote: >>> On 01/03/2014 10:56 PM, Arne Vajhøj wrote: >>> [ SNIP ] >>> >>>> There are plenty of cases where relational databases are not the best >>>> solution. >>>> >>>> Google, Facebook, Yahoo etc. did not go NoSQL just for fun. >>>> >>>> But I would still consider a relational database to be the default >>>> for persistence - what you use unless you have specific reasons >>>> not to. >>> >>> Quite a few important companies (so probably many more minor companies) >>> played with NoSQL for a bit, and then have backed off in various >>> degrees. Nobody went for NoSQL just for fun...most went for it because >>> they were sucked in by hype or misguided opinion. I'd estimate that the >>> majority of people have returned to RDBMSs. The fact that a number of >>> large companies have systems that are not relational is because you >>> can't throw away a few tens or hundreds of millions of $$ in a few >>> months or years. >>> >>> NoSQL is based on relaxing ACID, particularly consistency. You do that >>> by cheating your end users through increasing UI speed, while at the >>> same time decreasing the validity of your data. >> >> There is a lot more to it than that. >> >> NoSQL is really many different things. > >> There are some large distributed database systems. There are some >> which I would call modern replacements for traditional ISAM files. >> >> Some are AP. Some are CP. CouchDB and Neo4J are ACID. > > Well, we know at least one thing, NoSQL is not SQL...by definition. :-) > > What we should really do is get rid of the term NoSQL, since it > literally means "no SQL". We also have the problem that originally > "NoSQL" did refer to non-relational data stores that relaxed ACID > guarantees. Many, perhaps most, still do have relaxed guarantees. Some > NoSQL systems are ACID, I agree with you, but sometimes you have to make > the extra effort to obtain that functionality. > > I may date myself here. When people started producing "NoSQL" databases, > it was a large part of the definition that ACID guarantees were relaxed. > This is just historical fact. That some people started restoring ACID to > NoSQL doesn't mean that relaxation of consistency isn't still often a > key concept. > >> The big internet companies did not go to NoSQL due to the hype - as >> the hype was created by them going to NoSQL and they are not staying >> with NoSQL to avoid a large write off. They are went to and are >> staying with NoSQL, because the relational databases can not do >> the job. Relational databases and PB just does not work performance >> and cost wise. > > I think we should definitely drop the "NoSQL" terminology here. SQL per > se is irrelevant. I agree the terminology is a bit funky. SQL is really traditional relational. NoSQL is really non-relational based on new technology. NewSQL is really relational based on the same technologies as NoSQL. And no surprise that non-X databases are more diverse than X databases. > I find it somewhat astonishing that in 2014, with literally dozens or > hundreds or thousands of fast large-memory servers available to a > company, that a performant solution can't be accomplished with relational. Software is usually good at what it was designed for, but not good at what it was not designed for. Oracle, DB2, ASE, SQLServer, PostgreSQL, MySQL etc. was not designed to run in massive parallel configurations (most of them can not even run 2 node active-active). Typical the ability to do more with less code result in some overhead. Relational databases comes with a lot of stuff: SQL interface, transaction support etc. that makes life a lot easier for developers. But it does come with a cost. With MB and GB data, then that is typical not a problem. With TB data it may or may not be a problem. With PB data it is a problem. Different problems lead to different solutions. There are attempts to make a new kind of relational databases in the so called NewSQL databases (like Google Spanner) to bring back relational in big data. I think it is too early to say whether that will be a success or not. > Eric Brewer's CAP theorem is a nice academic notion. What I've often > wondered is why people jumped on ideas like that, most of which is > certainly sound, and tossed the baby out with the dishwater. A whack of > folks went wild on document databases - note that a document is > frequently self-contained and quite relational. Other people went wild > on re-inventing wheels differently: they totally abandoned relational > DBs and figured they wouldn't work at all in highly distributed systems. I actually like the focus on the CAP theorem. It has made it very clear to everybody that picking X may mean not picking Y. It is impossible to get everything and one need to prioritize what is most important. > Oddly enough, some of the "big internet companies" you allude to do in > fact use relational DBs that are highly distributed. The access latency > of such highly distributed RDBMSs is only marginally worse than the "Big > Data" systems we now usually think of. It also happens that when > companies do this, it's because they do in fact value relational feautures. Sure. Facebook and Yahoo are still big MySQL users (Google seems to be dropping MySQL). But again - it is different tools for different tasks. >> I am sure that there is a large portion of smaller companies that went >> NoSQL (typical something "ISAM like") that did so due to the hype. And >> I am sure that some of them regretted that they did so. > > A lot did, yes. I'm sure I mentioned before that about 15 years ago I > worked for a company that proposed to do very innovative stuff with WML > and HDML on cellphones. Probably the worst decision we ever made was to > switch from Allaire Cold Fusion to J2EE. All due to hype. CF was probably a lot more mature back then. But Java EE and the rest of Java evolved while CF is almost gone. So if the criteria was that the company want to be on a successful platform that would evolve and be supported for a long time, then it was the right decision. If the criteria was to make web development faster and cheaper from day one then I believe that it was a disaster. Side note: CF has merged into Java and Java EE later, but it has not resurrected CF. >> But persistence is not a one size fit all. Different requirements can >> lead to different solutions. >> >> C is critical in many contexts (like money transactions). But there are >> other contexts where it does not matter (does it matter that Facebook >> users in Mexico sees an update 5 minutes later than the Facebook users >> in Finland? No!). > > That's not a great consistency or transactional example, Arne. No > offense. It might be better to consider the problem of a *single > individual* doing something. It is the equivalent of the traditional transaction example of two attempts to withdraw money from the same bank account in two different cities. And it is also where the consistency problem in the AP system are seen in real life. Users served by different data centers see different information. >> There are quite a few of those C & ACID relational databases where >> for performance reasons the web apps in front actually cache and >> use data for N seconds even though the data may have been updated. In >> that case they are paying for C & ACID for no reason. > > This is true. But let's be real: an ACID consistency guarantee means > that your data may be a few seconds old but accurate. A non-ACID system > often means your data is not accurate all the time. If you've got an ORM > or web framework or HTTP server doing caching in front of an ACID > database, you've still got the C in ACID: the information might just be > a bit stale. The data are stored C somewhere, but they may be shown in a non-C way. Arne
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@address-in-sig.invalid> |
|---|---|
| Date | 2014-01-05 23:53 +0000 |
| Message-ID | <lacr92$65j$1@dont-email.me> |
| In reply to | #27242 |
On Sun, 05 Jan 2014 15:51:33 -0500, Arne Vajhøj wrote: > NewSQL is really relational based on the same technologies as NoSQL. > But, if the API is standards-compliant SQL and it is (preferably) ACID then do we give a stuff what the underlying storage mechanism is? I'd be happy to regard anything that fits this slot as an SQL DBMS. > And no surprise that non-X databases are more diverse than X databases. > Yes. > Oracle, DB2, ASE, SQLServer, PostgreSQL, MySQL etc. was not designed to > run in massive parallel configurations (most of them can not even run 2 > node active-active). > But some RDBMS are designed to do this. Remember the Red Brick Data Warehouse which appeared around 15 years ago? That could make a pretty good stab at this. It offered the ability to partition large tables and, when required, would run a query per partition in parallel before combining the results into a single result set (we partitioned the date by date so we could hold old and seldom accessed partitions on a nearline tape library). All its tables, indexes, and table partitions were mapped onto standard UNIX files, so does this count as NewSQL in your proposed terminology? Bear in mind that it was ACID compliant. I only saw it do this on a single server with a large (for the time) filestore but its an approach that could easily be generalised to support a distributed DB. > Different problems lead to different solutions. > Yes. >(like Google Spanner) > When you consider how long ago the RedBrick Data Warehouse did this sort of thing, is Spanner really cutting edge? -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2014-01-05 20:00 -0500 |
| Message-ID | <52ca0047$0$306$14726298@news.sunsite.dk> |
| In reply to | #27243 |
On 1/5/2014 6:53 PM, Martin Gregorie wrote: > On Sun, 05 Jan 2014 15:51:33 -0500, Arne Vajhøj wrote: >> NewSQL is really relational based on the same technologies as NoSQL. >> > But, if the API is standards-compliant SQL and it is (preferably) ACID > then do we give a stuff what the underlying storage mechanism is? I'd be > happy to regard anything that fits this slot as an SQL DBMS. > >> And no surprise that non-X databases are more diverse than X databases. >> > Yes. > >> Oracle, DB2, ASE, SQLServer, PostgreSQL, MySQL etc. was not designed to >> run in massive parallel configurations (most of them can not even run 2 >> node active-active). >> > But some RDBMS are designed to do this. Remember the Red Brick Data > Warehouse which appeared around 15 years ago? That could make a pretty > good stab at this. It offered the ability to partition large tables and, > when required, would run a query per partition in parallel before > combining the results into a single result set (we partitioned the date > by date so we could hold old and seldom accessed partitions on a nearline > tape library). > > All its tables, indexes, and table partitions were mapped onto standard > UNIX files, so does this count as NewSQL in your proposed terminology? It is not terms that I have invented. > Bear in mind that it was ACID compliant. > > I only saw it do this on a single server with a large (for the time) > filestore but its an approach that could easily be generalised to support > a distributed DB. > >> Different problems lead to different solutions. >> > Yes. > >> (like Google Spanner) >> > When you consider how long ago the RedBrick Data Warehouse did this sort > of thing, is Spanner really cutting edge? I know nothing about Red Brick. But it can have have been some of the same as NewSQL today. It is not that unusual that "new" technology are very similar to some earlier technology that just did not succeed commercially. But I do think that a little bit more than partitioning in multiple servers are necessary to qualify. Some of the traditional relational databases offer that. And you can do the same with any database using a library that can do it client side. In those cases it is often called sharding instead of partitioning. If you are using Hibernate then it is just a matter of using Hibernate Shards. Arne
[toc] | [prev] | [next] | [standalone]
| From | "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> |
|---|---|
| Date | 2014-01-03 15:38 +0000 |
| Message-ID | <VM-dnfqE68IcRFvPnZ2dnUVZ8oOdnZ2d@bt.com> |
| In reply to | #27052 |
Marcel Müller wrote:
> [...quite a bit of interesting stuff...]
Choosing this as a more-or-less arbitrary point to jump in, I have a question.
Given an existing relational database (or set of databases) that:
!) Is/are central to the business (i.e. not there just to "support" some
specific activity).
2) Is a fairly good relational expression of the underlying business model (but
see (3) and (7)).
3) Is old, old, old...
4) Is used by more than one application, which are not all written in the same
language
5) Has severe perfomance problems (caused by the nature of rhe business) even
when accessed via had-written SQL such that there is a fairly large amount of
explicit demnormalisation, and the write-measure-rewrite loop is a central part
of normal, everyday, application development/maintenance. And, even so, many of
the most important processes take long enough to cause very real operational
difficulties for customers.
6) Is not simple, in the sense that most of the "entities" that a user would
think in terms of do not correspond to rows of data in single tables.
7) Has historical quirks (see 3). Such as: no primary keys (the data has
primary keys at the logical level, but -- due to history -- the physical DBMS
itself doesn't know what they are, it just knows about a buch of unique
indexes). No FK constraints (again they are there in the logical model, but
not expressed physically).
Is my feeling that even attempting to use an ORM for developing brand new
applications against the database would be impossible and/or massively
counter-productive, actually defensible ? I.e: am I right to dismiss ORM /out
of hand/ ?
(Incidentally, of the relatively few database I've come across in 30 years of
programming, many fit that pattern).
-- chris
[toc] | [prev] | [next] | [standalone]
| From | "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> |
|---|---|
| Date | 2014-01-03 15:41 +0000 |
| Message-ID | <oJ6dnew11eg6RlvPnZ2dnUVZ8lWdnZ2d@bt.com> |
| In reply to | #27203 |
I wrote:
> [stuff]
Sorry about the double-posting. Damn client posted the message while I was
still spell-checking it.
The replied-to version is the one with the errors ;-(
-- chris
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2014-01-03 12:27 -0500 |
| Message-ID | <52c6f31e$0$306$14726298@news.sunsite.dk> |
| In reply to | #27203 |
On 1/3/2014 10:38 AM, Chris Uppal wrote: > Given an existing relational database (or set of databases) that: > > !) Is/are central to the business (i.e. not there just to "support" some > specific activity). > > 2) Is a fairly good relational expression of the underlying business model (but > see (3) and (7)). > > 3) Is old, old, old... > > 4) Is used by more than one application, which are not all written in the same > language > > 5) Has severe perfomance problems (caused by the nature of rhe business) even > when accessed via had-written SQL such that there is a fairly large amount of > explicit demnormalisation, and the write-measure-rewrite loop is a central part > of normal, everyday, application development/maintenance. And, even so, many of > the most important processes take long enough to cause very real operational > difficulties for customers. > > 6) Is not simple, in the sense that most of the "entities" that a user would > think in terms of do not correspond to rows of data in single tables. > > 7) Has historical quirks (see 3). Such as: no primary keys (the data has > primary keys at the logical level, but -- due to history -- the physical DBMS > itself doesn't know what they are, it just knows about a buch of unique > indexes). No FK constraints (again they are there in the logical model, but > not expressed physically). > > Is my feeling that even attempting to use an ORM for developing brand new > applications against the database would be impossible and/or massively > counter-productive, actually defensible ? I.e: am I right to dismiss ORM /out > of hand/ ? > > (Incidentally, of the relatively few database I've come across in 30 years of > programming, many fit that pattern). I don't think you should discard ORM without further investigation. Nothing of what you mention scream "not possible with ORM". Specifically I would expect: * no physical PK to work OK with the ORM when you declared the logical PK as id in the class * no physical FK constraints to work OK with the ORM * write-measure-rewrite to be fine with ORM * performance of ORM not to be worse than direct SQL * flexible mapping between classes and table to work OK with the ORM But based on the general state of the database, then I would say that the risk of running into a problem is much higher than with a from scratch database. And it is given that you can not generate the classes and/or the mapping automatically from the tables given the description. And all ORM's are not the same, so some may work better than other with a scenario as the one described. [and those types of scenarios are rather common!] If you have time to research (POC) ORM, then I think you should. If you do not have time, then you should probably discard ORM due to the risk of problems due to non-optimal environment. Arne
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2014-01-03 18:49 -0400 |
| Message-ID | <f8Hxu.161604$Ks5.64293@fx08.iad> |
| In reply to | #27203 |
On 01/03/2014 11:38 AM, Chris Uppal wrote: > Marcel Müller wrote: > >> [...quite a bit of interesting stuff...] > > Choosing this as a more-or-less arbitrary point to jump in, I have a question. This is an elegant and diplomatic way of saying, there are so many frigging long posts already, I can't keep track. :-) You should work for the UN perhaps. > Given an existing relational database (or set of databases) that: > > !) Is/are central to the business (i.e. not there just to "support" some > specific activity). > > 2) Is a fairly good relational expression of the underlying business model (but > see (3) and (7)). > > 3) Is old, old, old... > > 4) Is used by more than one application, which are not all written in the same > language > > 5) Has severe perfomance problems (caused by the nature of rhe business) even > when accessed via had-written SQL such that there is a fairly large amount of > explicit demnormalisation, and the write-measure-rewrite loop is a central part > of normal, everyday, application development/maintenance. And, even so, many of > the most important processes take long enough to cause very real operational > difficulties for customers. > > 6) Is not simple, in the sense that most of the "entities" that a user would > think in terms of do not correspond to rows of data in single tables. > > 7) Has historical quirks (see 3). Such as: no primary keys (the data has > primary keys at the logical level, but -- due to history -- the physical DBMS > itself doesn't know what they are, it just knows about a buch of unique > indexes). No FK constraints (again they are there in the logical model, but > not expressed physically). > > Is my feeling that even attempting to use an ORM for developing brand new > applications against the database would be impossible and/or massively > counter-productive, actually defensible ? I.e: am I right to dismiss ORM /out > of hand/ ? > > (Incidentally, of the relatively few database I've come across in 30 years of > programming, many fit that pattern). > > -- chris > > You're not wrong in general, Chris. I just this past year saw a database that had no primary keys, and about 4 or 5 FKs, and about 50 tables. As you may surmise, it was about as denormalized and non-validated as you can imagine. About 6 or 7 years ago an Adabas database that I had to work with was automatically translated to an RDBMS: this was not very successful - the subsequent attempt to use TopLink on it was painful. And I've seen plenty of Oracle, Sybase, MS SQL Server, MySQL, Postgres etc setups which prove your point #5...as in, any means of accessing the DB would be difficult. Having said that, I still believe that an ORM is usually better than a lower-level API for accessing good *or* bad APIs. AHS -- When a true genius appears, you can know him by this sign: that all the dunces are in a confederacy against him. -- Jonathan Swift
[toc] | [prev] | [next] | [standalone]
| From | "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> |
|---|---|
| Date | 2014-01-03 15:39 +0000 |
| Message-ID | <vYudnRQoKMsqRFvPnZ2dnUVZ7t2dnZ2d@bt.com> |
| In reply to | #27052 |
Marcel Müller wrote:
> [...quite a bit of interesting stuff...]
Choosing this as a more-or-less arbitrary point to jump in, I have a question.
Given an existing relational database (or set of databases) that:
!) Is/are central to the business (i.e. not there just to "support" some
specific activity).
2) Is a fairly good relational expression of the underlying business model (but
see (3) and (7)).
3) Is old, old, old...
4) Is used by more than one application, which are not all written in the same
language
5) Has severe performance problems (caused by the nature of rhea business) even
when accessed via had-written SQL such that there is a fairly large amount of
explicit denormalisation, and the write-measure-rewrite loop is a central part
of normal, everyday, application development/maintenance. And, even so, many of
the most important processes take long enough to cause very real operational
difficulties for customers.
6) Is not simple, in the sense that most of the "entities" that a user would
think in terms of do not correspond to rows of data in single tables.
7) Has historical quirks (see 3). Such as: no primary keys (the data has
primary keys at the logical level, but -- due to history -- the physical DBMS
itself doesn't know what they are, it just knows about a bunch of unique
indexes). No FK constraints (again they are there in the logical model, but
not expressed physically).
Is my feeling that even attempting to use an ORM for developing brand new
applications against the database would be impossible and/or massively
counter-productive, actually defensible ? I.e: am I right to dismiss ORM /out
of hand/ ?
(Incidentally, of the relatively few database I've come across in 30 years of
programming, many fit that pattern).
-- chris
[toc] | [prev] | [next] | [standalone]
| From | Kevin McMurtrie <mcmurtrie@pixelmemory.us> |
|---|---|
| Date | 2013-12-22 16:11 -0800 |
| Message-ID | <mcmurtrie-3C7205.16113722122013@c-61-68-245-199.per.connect.net.au> |
| In reply to | #27043 |
In article <%JGtu.29103$Wm1.26832@fx17.iad>, Daniel Pitts <newsgroup.nospam@virtualinfinity.net> wrote: > Hey everyone, > > This is cross-posted to cl.java.programmer and cl.php. > > I've been doing some thinking about my experiences with various ORMs, > both positive and negative. I find that I often stretch systems to > there limits, and end up doing a lot of meta-programming to solve > problems that I've always felt should have been solved by the core > libraries. Mostly to follow DRY and KISS principals in the core > business code. > > I'm curious if others' have found the same things I have, or if they've > been satisfied doing things other ways, and if so what ORMs they use. > > I've had experience with the following Java ORMs: > * Hibernate (version 3, using Annotations for instance) > * Ibatis (many years ago, don't remember the version. around 2006) > * Straight JDBC. Not exactly an ORM :-) > > And then one non-Java ORM: Doctrine, which is modeled after Hibernate, > including most of its flaws, but missing some of its features. > > > So, my question to the groups, what ORMs have you used, and what did you > like and hate about each of them? I'm not trying to start a flame war, > so please keep it to personal experiences with projects which used them. > > I'm interested in use-cases from simple small one-off applications to > complex enterprise-level systems, and highly-scalable systems. > > Please include details like "it's easier to maintain <x> type of changes > with our approach, but <y> is very difficult" etc... > > Thanks for your consideration, > Daniel. I don't like ORM utilities much because they rarely model all of the complex relationships and behaviors, for better or worse, that may exist in SQL. You end up spending at least as much time working around those limitations as time initially saved. Simpler data works fine in ORM, but simpler data is isn't the complex task ORM tries to solve. That leaves many ORM utilities as too enormous, too complex, too slow, and still a poor fit for SQL. I see ORM as potentially being an excellent fit for document stores but I have little experience with those.
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-12-29 23:08 -0500 |
| Message-ID | <52c0f1cd$0$297$14726298@news.sunsite.dk> |
| In reply to | #27055 |
On 12/22/2013 7:11 PM, Kevin McMurtrie wrote: > That leaves many ORM utilities as too enormous, too complex, too slow, > and still a poor fit for SQL. I see ORM as potentially being an > excellent fit for document stores but I have little experience with > those. ???? What would be the point of an ORM that maps to a relational data model in connection with a non-relational database? Arne
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-12-30 17:36 -0400 |
| Message-ID | <AHlwu.109100$tR7.48440@fx22.iad> |
| In reply to | #27055 |
On 12/22/2013 08:11 PM, Kevin McMurtrie wrote: > In article <%JGtu.29103$Wm1.26832@fx17.iad>, > Daniel Pitts <newsgroup.nospam@virtualinfinity.net> wrote: > >> Hey everyone, >> >> This is cross-posted to cl.java.programmer and cl.php. >> >> I've been doing some thinking about my experiences with various ORMs, >> both positive and negative. I find that I often stretch systems to >> there limits, and end up doing a lot of meta-programming to solve >> problems that I've always felt should have been solved by the core >> libraries. Mostly to follow DRY and KISS principals in the core >> business code. >> >> I'm curious if others' have found the same things I have, or if they've >> been satisfied doing things other ways, and if so what ORMs they use. >> >> I've had experience with the following Java ORMs: >> * Hibernate (version 3, using Annotations for instance) >> * Ibatis (many years ago, don't remember the version. around 2006) >> * Straight JDBC. Not exactly an ORM :-) >> >> And then one non-Java ORM: Doctrine, which is modeled after Hibernate, >> including most of its flaws, but missing some of its features. >> >> >> So, my question to the groups, what ORMs have you used, and what did you >> like and hate about each of them? I'm not trying to start a flame war, >> so please keep it to personal experiences with projects which used them. >> >> I'm interested in use-cases from simple small one-off applications to >> complex enterprise-level systems, and highly-scalable systems. >> >> Please include details like "it's easier to maintain <x> type of changes >> with our approach, but <y> is very difficult" etc... >> >> Thanks for your consideration, >> Daniel. > > I don't like ORM utilities much because they rarely model all of the > complex relationships and behaviors, for better or worse, that may exist > in SQL. You end up spending at least as much time working around those > limitations as time initially saved. > > Simpler data works fine in ORM, but simpler data is isn't the complex > task ORM tries to solve. > > That leaves many ORM utilities as too enormous, too complex, too slow, > and still a poor fit for SQL. I see ORM as potentially being an > excellent fit for document stores but I have little experience with > those. > To echo Arne's comment, an "excellent fit for document stores"??? How so? If the document is well-modeled by a relational calculus, why model it as a document? The current notion of a document is that of groups of semi-structured or non-structured data that don't necessarily adhere to any schema. Which is non-relational. There are fundamental differences here. I haven't encountered the problems you have, apparently, with ORMs. Data is complex, relational data is obviously just as complex, and any method of querying or manipulating real relational data is often hard. And considering major ORMs (not just Java), and the amount of educated effort that has gone into them, there are not many people who are well-advised to routinely use SQL directly if they have other options...not unless they are RDBMS specialists, and that's what they do for a living. Are you one? I'm not. I'll say this: Java language limitations have hurt Java ORMs, and it's not the fault of the ORM developers: I know a few of them. The JPA Criteria API is a sign of the apocalypse. It's unfortunately informed by folks who are both struggling with Java limitations and have experience with native implementations. C# LINQ and Scala Squeryl are conceptually light years ahead of Java ORMs. AHS -- When a true genius appears, you can know him by this sign: that all the dunces are in a confederacy against him. -- Jonathan Swift
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2013-12-30 22:13 +0000 |
| Message-ID | <l9sr6p$189$1@news.albasani.net> |
| In reply to | #27137 |
On 30/12/13 21:36, Arved Sandstrom wrote: > Data is complex, relational data is obviously just as complex, and any > method of querying or manipulating real relational data is often hard. > And considering major ORMs (not just Java), and the amount of educated > effort that has gone into them, there are not many people who are > well-advised to routinely use SQL directly if they have other > options...not unless they are RDBMS specialists, and that's what they do > for a living. Are you one? I'm not. Ah. So mining is complex and labour intesive, so lets not learn how to use an excavator, but instead develop tools to allow us to organise huge gangs of navvies with picks and shovels, because that's easier for us lazy shits than mastering the controls on a dump truck or draglinme excavator. If you cant manage relational databases, you shouldn't be messing with big data. -- Ineptocracy (in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-12-30 22:09 -0400 |
| Message-ID | <cHpwu.107684$Rt7.47128@fx27.iad> |
| In reply to | #27138 |
On 12/30/2013 06:13 PM, The Natural Philosopher wrote: > On 30/12/13 21:36, Arved Sandstrom wrote: >> Data is complex, relational data is obviously just as complex, and any >> method of querying or manipulating real relational data is often hard. >> And considering major ORMs (not just Java), and the amount of educated >> effort that has gone into them, there are not many people who are >> well-advised to routinely use SQL directly if they have other >> options...not unless they are RDBMS specialists, and that's what they do >> for a living. Are you one? I'm not. > > Ah. So mining is complex and labour intesive, so lets not learn how to > use an excavator, but instead develop tools to allow us to organise huge > gangs of navvies with picks and shovels, because that's easier for us > lazy shits than mastering the controls on a dump truck or draglinme > excavator. > > If you cant manage relational databases, you shouldn't be messing with > big data. > > Identify yourself by your real name, doorknob. Maybe then you can put up or shut up. Learn spelling and grammar too - those skills help when you converse with adults. AHS -- When a true genius appears, you can know him by this sign: that all the dunces are in a confederacy against him. -- Jonathan Swift
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2013-12-31 11:30 +0000 |
| Message-ID | <l9u9sk$lju$1@news.albasani.net> |
| In reply to | #27147 |
On 31/12/13 02:09, Arved Sandstrom wrote: > On 12/30/2013 06:13 PM, The Natural Philosopher wrote: >> On 30/12/13 21:36, Arved Sandstrom wrote: >>> Data is complex, relational data is obviously just as complex, and any >>> method of querying or manipulating real relational data is often hard. >>> And considering major ORMs (not just Java), and the amount of educated >>> effort that has gone into them, there are not many people who are >>> well-advised to routinely use SQL directly if they have other >>> options...not unless they are RDBMS specialists, and that's what they do >>> for a living. Are you one? I'm not. >> >> Ah. So mining is complex and labour intesive, so lets not learn how to >> use an excavator, but instead develop tools to allow us to organise huge >> gangs of navvies with picks and shovels, because that's easier for us >> lazy shits than mastering the controls on a dump truck or draglinme >> excavator. >> >> If you cant manage relational databases, you shouldn't be messing with >> big data. >> >> > Identify yourself by your real name, doorknob. Maybe then you can put up > or shut up. > > Learn spelling and grammar too - those skills help when you converse > with adults. > So no counter argument, just an ad hominem attack. You are Jerry Stuckle and I claim my $5. > AHS -- Ineptocracy (in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.
[toc] | [prev] | [next] | [standalone]
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web