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 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-12-29 23:06 -0500 |
| Message-ID | <52c0f159$0$297$14726298@news.sunsite.dk> |
| In reply to | #27107 |
On 12/29/2013 10:54 PM, Qu0ll wrote: > "Arne Vajhøj" wrote in message > news:52c0eca1$0$300$14726298@news.sunsite.dk... > >>> If you want, you can talk all you want about it in c.l.j.p. But this >>> does not belong in c.l.p. >> >> So you keep saying. >> >> But just saying it does not make it correct. >> >> I just googled and found the original comp.lang.php charter >> from 2002. >> >> I says: >> >> "Since database connectivity is a large part of PHP, it will >> be considered topical in comp.lang.php." >> >> Unless you have changed the charter since then (Google can not >> find that, but that does not prove that it does not exist), then >> that means that ORM in PHP is on topic for comp.lang.php. > > No, no, no Arne! Don't throw facts at a troll, they do not know how to > handle them! > > I found this which I think is a more recent c.l.p charter and is the one > that's obviously in effect now: > > "Posts are considered topical for comp.lang.php if they relate to PHP > directly or indirectly but only if Jerry Stuckle approves of either the > post, the content or the poster. > > Note: Jerry (who is the official owner of c.l.p) does *NOT* permit any > posts which have any of the following attributes: > > 1. They are posted by someone who has never posted in c.l.p before. > 2. The poster uses a Gmail address. > 3. The poster chooses not to publish their actual name. > 4. The poster or post makes Jerry look like a fool. > > Please email Jerry directly if any of this is not clear." > > Unfortunately point (4) results in most posts being declared spam by > said owner. Please don't take a job within international diplomacy. :-) Arne
[toc] | [prev] | [next] | [standalone]
| From | "Qu0ll" <Qu0llSixFour@gmail.com> |
|---|---|
| Date | 2013-12-30 15:21 +1100 |
| Message-ID | <9rqdnS9Kl6hoaV3PnZ2dnUVZ_jGdnZ2d@westnet.com.au> |
| In reply to | #27109 |
"Arne Vajhøj" wrote in message news:52c0f159$0$297$14726298@news.sunsite.dk... > Please don't take a job within international diplomacy. True, I concede that was a bit below the belt. But very little annoys me more than someone who attempts to censor free speech. I apologise for going a little over-the-top. Sometimes passion for fairness and fair-play makes me do things in the heat of the moment I later regret... -- And loving it, -Qu0ll (Rare, not extinct) _________________________________________________ Qu0llSixFour@gmail.com [Replace the "SixFour" with numbers to email me]
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2013-12-30 08:04 -0500 |
| Message-ID | <l9rr04$t40$2@dont-email.me> |
| In reply to | #27105 |
On 12/29/2013 10:46 PM, Arne Vajhøj wrote: > On 12/22/2013 4:34 PM, Jerry Stuckle wrote: >> On 12/22/2013 4:20 PM, Arne Vajhøj wrote: >>> On 12/22/2013 4:09 PM, Jerry Stuckle wrote: >>>> On 12/22/2013 4:04 PM, Arne Vajhøj wrote: >>>>> On 12/22/2013 3:47 PM, Jerry Stuckle wrote: >>>>>> On 12/22/2013 3:38 PM, Arne Vajhøj wrote: >>>>>>> On 12/22/2013 3:17 PM, Jerry Stuckle wrote: >>>>>>>> On 12/22/2013 2:05 PM, Daniel Pitts 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... >>>>>>>> >>>>>>>> Is there a PHP question in there? I don't see one... >>>>>>> >>>>>>> Doctrine is PHP. And the question is open ended so other PHP >>>>>>> ORM's could be included in discussion. >>>>>> >>>>>> I still don't see a PHP question here. I see some product >>>>>> questions - >>>>>> which would be better suited in a newsgroup for those applications. >>>>>> >>>>>> Just because something uses PHP does not mean it is appropriate for a >>>>>> PHP language newsgroup. >>>>>> >>>>>> But I know some people don't believe in segregation of newsgroups and >>>>>> think anything should be able to be asked in any newsgroup. >>>>> >>>>> ORM's are not applications. They are libraries. >>>>> >>>>> And since it is question asking for comparison, then a group >>>>> for a specific library is not a good choice. >>>>> >>>>> Instead a group with people with experience and interest in >>>>> different ways of database access from PHP is needed. >>>>> >>>>> comp.lang.php does not seem that far fetched. >>>>> >>>>> Obviously comp.lang.php.databaseaccess or >>>>> comp.lang.php.databaseaccess.orm >>>>> would be even better if such exists. >>>> >>>> Yes, an ORM-related newsgroup would be more appropriate. There you >>>> have >>>> people who know the advantages and disadvantages of various ORM's. >>> >>> ORM's are language specific. So it would need to be a PHP ORM group >>> to cover PHP. >>> >>> Does one exist? >>> >>>> Few, if any, in the language-related newsgroups will have used an ORM, >>>> and if they have, they have very limited experience. >>> >>> That depends on the language. >>> >>> In languages like Java and C# it would be >90% that have used an ORM. >>> >>> It is probably much less in PHP as ORM's are not as widely used >>> in the PHP world. >>> >>> But I suspect that Daniel even may be interested in knowing more >>> about why it is so. >> >> If you want, you can talk all you want about it in c.l.j.p. But this >> does not belong in c.l.p. > > So you keep saying. > > But just saying it does not make it correct. > > I just googled and found the original comp.lang.php charter > from 2002. > > I says: > > "Since database connectivity is a large part of PHP, it will > be considered topical in comp.lang.php." > > Unless you have changed the charter since then (Google can not > find that, but that does not prove that it does not exist), then > that means that ORM in PHP is on topic for comp.lang.php. > > Arne > > > > ORM is not database connectivity. But you're too stoopid to understand the difference. Just like some other Java programmers. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-12-30 12:32 -0500 |
| Message-ID | <52c1ae33$0$304$14726298@news.sunsite.dk> |
| In reply to | #27117 |
On 12/30/2013 8:04 AM, Jerry Stuckle wrote: > On 12/29/2013 10:46 PM, Arne Vajhøj wrote: >> On 12/22/2013 4:34 PM, Jerry Stuckle wrote: >>> On 12/22/2013 4:20 PM, Arne Vajhøj wrote: >>>> On 12/22/2013 4:09 PM, Jerry Stuckle wrote: >>>>> On 12/22/2013 4:04 PM, Arne Vajhøj wrote: >>>>>> On 12/22/2013 3:47 PM, Jerry Stuckle wrote: >>>>>>> On 12/22/2013 3:38 PM, Arne Vajhøj wrote: >>>>>>>> On 12/22/2013 3:17 PM, Jerry Stuckle wrote: >>>>>>>>> On 12/22/2013 2:05 PM, Daniel Pitts 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... >>>>>>>>> >>>>>>>>> Is there a PHP question in there? I don't see one... >>>>>>>> >>>>>>>> Doctrine is PHP. And the question is open ended so other PHP >>>>>>>> ORM's could be included in discussion. >>>>>>> >>>>>>> I still don't see a PHP question here. I see some product >>>>>>> questions - >>>>>>> which would be better suited in a newsgroup for those applications. >>>>>>> >>>>>>> Just because something uses PHP does not mean it is appropriate >>>>>>> for a >>>>>>> PHP language newsgroup. >>>>>>> >>>>>>> But I know some people don't believe in segregation of newsgroups >>>>>>> and >>>>>>> think anything should be able to be asked in any newsgroup. >>>>>> >>>>>> ORM's are not applications. They are libraries. >>>>>> >>>>>> And since it is question asking for comparison, then a group >>>>>> for a specific library is not a good choice. >>>>>> >>>>>> Instead a group with people with experience and interest in >>>>>> different ways of database access from PHP is needed. >>>>>> >>>>>> comp.lang.php does not seem that far fetched. >>>>>> >>>>>> Obviously comp.lang.php.databaseaccess or >>>>>> comp.lang.php.databaseaccess.orm >>>>>> would be even better if such exists. >>>>> >>>>> Yes, an ORM-related newsgroup would be more appropriate. There you >>>>> have >>>>> people who know the advantages and disadvantages of various ORM's. >>>> >>>> ORM's are language specific. So it would need to be a PHP ORM group >>>> to cover PHP. >>>> >>>> Does one exist? >>>> >>>>> Few, if any, in the language-related newsgroups will have used an ORM, >>>>> and if they have, they have very limited experience. >>>> >>>> That depends on the language. >>>> >>>> In languages like Java and C# it would be >90% that have used an ORM. >>>> >>>> It is probably much less in PHP as ORM's are not as widely used >>>> in the PHP world. >>>> >>>> But I suspect that Daniel even may be interested in knowing more >>>> about why it is so. >>> >>> If you want, you can talk all you want about it in c.l.j.p. But this >>> does not belong in c.l.p. >> >> So you keep saying. >> >> But just saying it does not make it correct. >> >> I just googled and found the original comp.lang.php charter >> from 2002. >> >> I says: >> >> "Since database connectivity is a large part of PHP, it will >> be considered topical in comp.lang.php." >> >> Unless you have changed the charter since then (Google can not >> find that, but that does not prove that it does not exist), then >> that means that ORM in PHP is on topic for comp.lang.php. > > ORM is not database connectivity. If it is what the PHP code is using to access the database, then it is providing database connectivity. > But you're too stoopid to understand > the difference. Name calling is not a very convincing argumentation. Arne
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2013-12-30 12:47 -0500 |
| Message-ID | <l9sbjk$787$2@dont-email.me> |
| In reply to | #27120 |
On 12/30/2013 12:32 PM, The well-known TROLL Arne Vajhøj wrote: > On 12/30/2013 8:04 AM, Jerry Stuckle wrote: >> On 12/29/2013 10:46 PM, Arne Vajhøj wrote: >>> On 12/22/2013 4:34 PM, Jerry Stuckle wrote: >>>> On 12/22/2013 4:20 PM, Arne Vajhøj wrote: >>>>> On 12/22/2013 4:09 PM, Jerry Stuckle wrote: >>>>>> On 12/22/2013 4:04 PM, Arne Vajhøj wrote: >>>>>>> On 12/22/2013 3:47 PM, Jerry Stuckle wrote: >>>>>>>> On 12/22/2013 3:38 PM, Arne Vajhøj wrote: >>>>>>>>> On 12/22/2013 3:17 PM, Jerry Stuckle wrote: >>>>>>>>>> On 12/22/2013 2:05 PM, Daniel Pitts 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... >>>>>>>>>> >>>>>>>>>> Is there a PHP question in there? I don't see one... >>>>>>>>> >>>>>>>>> Doctrine is PHP. And the question is open ended so other PHP >>>>>>>>> ORM's could be included in discussion. >>>>>>>> >>>>>>>> I still don't see a PHP question here. I see some product >>>>>>>> questions - >>>>>>>> which would be better suited in a newsgroup for those applications. >>>>>>>> >>>>>>>> Just because something uses PHP does not mean it is appropriate >>>>>>>> for a >>>>>>>> PHP language newsgroup. >>>>>>>> >>>>>>>> But I know some people don't believe in segregation of newsgroups >>>>>>>> and >>>>>>>> think anything should be able to be asked in any newsgroup. >>>>>>> >>>>>>> ORM's are not applications. They are libraries. >>>>>>> >>>>>>> And since it is question asking for comparison, then a group >>>>>>> for a specific library is not a good choice. >>>>>>> >>>>>>> Instead a group with people with experience and interest in >>>>>>> different ways of database access from PHP is needed. >>>>>>> >>>>>>> comp.lang.php does not seem that far fetched. >>>>>>> >>>>>>> Obviously comp.lang.php.databaseaccess or >>>>>>> comp.lang.php.databaseaccess.orm >>>>>>> would be even better if such exists. >>>>>> >>>>>> Yes, an ORM-related newsgroup would be more appropriate. There you >>>>>> have >>>>>> people who know the advantages and disadvantages of various ORM's. >>>>> >>>>> ORM's are language specific. So it would need to be a PHP ORM group >>>>> to cover PHP. >>>>> >>>>> Does one exist? >>>>> >>>>>> Few, if any, in the language-related newsgroups will have used an >>>>>> ORM, >>>>>> and if they have, they have very limited experience. >>>>> >>>>> That depends on the language. >>>>> >>>>> In languages like Java and C# it would be >90% that have used an ORM. >>>>> >>>>> It is probably much less in PHP as ORM's are not as widely used >>>>> in the PHP world. >>>>> >>>>> But I suspect that Daniel even may be interested in knowing more >>>>> about why it is so. >>>> >>>> If you want, you can talk all you want about it in c.l.j.p. But this >>>> does not belong in c.l.p. >>> >>> So you keep saying. >>> >>> But just saying it does not make it correct. >>> >>> I just googled and found the original comp.lang.php charter >>> from 2002. >>> >>> I says: >>> >>> "Since database connectivity is a large part of PHP, it will >>> be considered topical in comp.lang.php." >>> >>> Unless you have changed the charter since then (Google can not >>> find that, but that does not prove that it does not exist), then >>> that means that ORM in PHP is on topic for comp.lang.php. >> >> ORM is not database connectivity. > > If it is what the PHP code is using to access the database, then > it is providing database connectivity. > >> But you're too stoopid to understand >> the difference. > > Name calling is not a very convincing argumentation. > > Arne > > > > > The truth hurts, doesn't it? -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Qu0ll" <Qu0llSixFour@gmail.com> |
|---|---|
| Date | 2013-12-31 08:23 +1100 |
| Message-ID | <t6adnbPGiNMUeVzPnZ2dnUVZ_vednZ2d@westnet.com.au> |
| In reply to | #27124 |
"Jerry Stuckle" wrote in message news:l9sbjk$787$2@dont-email.me... > The truth hurts, doesn't it? Well yes Jerry, clearly it does. Your own precious charter which you keep referencing has shown you to be wrong (again). You have now reduced yourself to labelling Java programmers (and anyone who disagrees with you) as "stoopid" as well as being trolls. At least there is no doubt in anyone's mind who the "troll" is here in this hijacked thread. I conceded I went too far in highlighting your arrogance, ignorance and highly inappropriate behaviour but this in no way excuses your actions or justifies them. I also apologised. I suggest you take a slice of humble pie yourself. You *really* need to take-away from this that you do not own the internet or Usenet and if you continue to attempt your own form of censorship then others will have a problem with that. -- And loving it, -Qu0ll (Rare, not extinct) _________________________________________________ Qu0llSixFour@gmail.com [Replace the "SixFour" with numbers to email me]
[toc] | [prev] | [next] | [standalone]
| From | Doug Miller <doug_at_milmac_dot_com@example.com> |
|---|---|
| Date | 2013-12-30 19:45 +0000 |
| Message-ID | <XnsA2A69608DDCD5dougmilmaccom@78.46.70.116> |
| In reply to | #27120 |
Arne Vajhøj <arne@vajhoej.dk> wrote in news:52c1ae33$0$304$14726298@news.sunsite.dk: > On 12/30/2013 8:04 AM, Jerry Stuckle wrote: >> But you're too stoopid to understand the difference. > > Name calling is not a very convincing argumentation. No, of course not, but it's the norm for Jerry whenever someone dares to disagree with him. Just do what most of the rest of us who've been around this group for a while have already done long ago: killfile him, and move on with your life.
[toc] | [prev] | [next] | [standalone]
| From | Ricardo Palomaes <rpmdisguise-java@nowhere.com> |
|---|---|
| Date | 2013-12-30 19:20 +0100 |
| Message-ID | <l9sdh4$s5h$1@speranza.aioe.org> |
| In reply to | #27117 |
El 30/12/13 14:04, Jerry Stuckle escribió: > ORM is not database connectivity. But you're too stoopid to > understand the difference. Just like some other Java programmers. NOW it is clear who's the troll.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2013-12-30 18:34 +0000 |
| Message-ID | <l9sebj$7ph$1@news.albasani.net> |
| In reply to | #27128 |
On 30/12/13 18:20, Ricardo Palomaes wrote: > El 30/12/13 14:04, Jerry Stuckle escribió: >> ORM is not database connectivity. But you're too stoopid to >> understand the difference. Just like some other Java programmers. > > > NOW it is clear who's the troll. > > what took you so long... -- 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 | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2013-12-30 14:27 -0500 |
| Message-ID | <l9shfb$eb4$1@dont-email.me> |
| In reply to | #27129 |
On 12/30/2013 1:34 PM, The Natural Philosopher wrote: > On 30/12/13 18:20, Ricardo Palomaes wrote: >> El 30/12/13 14:04, Jerry Stuckle escribió: >>> ORM is not database connectivity. But you're too stoopid to >>> understand the difference. Just like some other Java programmers. >> >> >> NOW it is clear who's the troll. >> >> > what took you so long... > Ah, the anonymous troll speaks up again! He's afraid to use his real name because he doesn't want us to find out he's neither a programmer or the electrical engineer he claims to be. And he doesn't like me because I've caught him too many times in his lies. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Marcel Müller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2013-12-22 22:26 +0100 |
| Message-ID | <52b75900$0$9519$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #27043 |
On 22.12.13 20.05, Daniel Pitts wrote: > This is cross-posted to cl.java.programmer and cl.php. The topic is unlikely to fit to php. F'up to java only. > 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. First of all you need to mention what ORMs are designed for. They are intended to make SQL databases suitable for OO programming style and/or non-relational data models. At the end OO expressions are turned into SQL and then to an execution plan. From that you can see that there is exactly one thing superfluous in this scenario: SQL. It is the bottleneck where all expressions must fit to. But it does not add any functionality, quite the contrary. It is just a emulation level for compatibility, like a SATA adapter enables a SATA drive to be used with an IDE port. You see, I am not really a friend of ORM. If a relational data model does not fit your needs, you first should consider to use a non relational database, rather than to normalize the data model to fit into a relational DB, and use an ORM to hide that from the application layer. ORMs are known to slow things down. I don't think that this is true in general. But the ORM layer makes some trivial looking expressions amazingly complex. So it is not that easy for the programmer to estimate the complexity of a code block, without knowledge about the entire ORM layer and the base data model in SQL. In fact I have redesigned many code parts because of this. 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. Of course, if you are stuck with an SQL DB for some reason and you need to adapt to an OO application layer ORM might be a choice. But if the data model in the DB is not intended for ORM usage, you won't get happy, because there are almost always properties of the data model that are not correctly modeled in SQL. However, to get more detailed information you need to phrase your questions more precisely. What are your topics of interest? Performance? Maintainability? What kind of data model do you intend to use? Many entities? Or many properties? What kind of relations? Polymorphism? Marcel
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2013-12-29 23:17 -0500 |
| Message-ID | <52c0f3dc$0$298$14726298@news.sunsite.dk> |
| In reply to | #27052 |
On 12/22/2013 4:26 PM, Marcel Müller wrote: > On 22.12.13 20.05, Daniel Pitts wrote: >> 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. > > First of all you need to mention what ORMs are designed for. They are > intended to make SQL databases suitable for OO programming style and/or > non-relational data models. At the end OO expressions are turned into > SQL and then to an execution plan. > From that you can see that there is exactly one thing superfluous in > this scenario: SQL. It is the bottleneck where all expressions must fit > to. But it does not add any functionality, quite the contrary. It is > just a emulation level for compatibility, like a SATA adapter enables a > SATA drive to be used with an IDE port. > > You see, I am not really a friend of ORM. If a relational data model > does not fit your needs, you first should consider to use a non > relational database, rather than to normalize the data model to fit into > a relational DB, and use an ORM to hide that from the application layer. Yes and no. If you could get non-relational databases with same transactional support, same tools, same vendor support etc.. And if all access to the database is OO based. Then that would be obvious. But the non-relational databases has not reached the same maturity level (as a summary term for the above) as relational databases. And it is common to have the same databases used by modern OO based software also to be used by non-OO legacy software (like 20 year old COBOL programs). > ORMs are known to slow things down. I don't think that this is true in > general. But the ORM layer makes some trivial looking expressions > amazingly complex. So it is not that easy for the programmer to estimate > the complexity of a code block, without knowledge about the entire ORM > layer and the base data model in SQL. In fact I have redesigned many > code parts because of this. Oh - I have seen my share of that. It should be mandatory for developers writing code using ORM to do some testing with the logging of actual SQL statements executed turned on. It reveals what is going on without having to know so much about the inside of the ORM. > Of course, if you are stuck with an SQL DB for some reason and you need > to adapt to an OO application layer ORM might be a choice. But if the > data model in the DB is not intended for ORM usage, you won't get happy, > because there are almost always properties of the data model that are > not correctly modeled in SQL. It seems as if very large parts of the Java, .NET and Ruby worlds are able to make it work. Arne
[toc] | [prev] | [next] | [standalone]
| From | Marcel Müller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2013-12-31 11:12 +0100 |
| Message-ID | <52c29885$0$9508$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #27111 |
On 30.12.13 05.17, Arne Vajhøj wrote: >> You see, I am not really a friend of ORM. If a relational data model >> does not fit your needs, you first should consider to use a non >> relational database, rather than to normalize the data model to fit into >> a relational DB, and use an ORM to hide that from the application layer. > > Yes and no. > > If you could get non-relational databases with same transactional > support, same tools, same vendor support etc.. > > And if all access to the database is OO based. > > Then that would be obvious. > > But the non-relational databases has not reached the same maturity level > (as a summary term for the above) as relational databases. You are right. We are in an intermediate situation where relational DBMS are integrated into backup, service and management processes by far better than the new OO or document based DBMS. And of course, the administrators have experience with them. Because of this I did the last larger project still with MSSQL (in snapshot isolation mode). But the data model did not depend on the DB. I simply store XML documents with revision information. In fact the DBMS backend was activated about 4 month after the project started. So when the time is come we could easily move to Mongo or whatever. What I miss by far more is a standard, how to use NoSQL DBMS. So anybody writes its own framework with its own advantages and disadvantages. I.e. we had to write a query optimizer and an index provider. Things that relational DBMS have at a highly optimized level. Unfortunately they are almost unusable if the data model does not fit to them. And with ORM often only a few aspects of the DBMS performance reach the application level. Others mainly help to solve the problems that did not exist before. > And it is common to have the same databases used by modern OO based > software also to be used by non-OO legacy software (like 20 year > old COBOL programs). COBOL, dark chapter - from the present point of view. And SAP extended the COBOL style by ABAP. [performance] > It should be mandatory for developers writing code using ORM to do some > testing with the logging of actual SQL statements executed turned on. It > reveals what is going on without having to know so much about the inside > of the ORM. Well, true, but from the programmers point of view, I do not always want to go that deep into the framework. This is like digging down to the assembler level in former times. However, at least when doing function programming (without a functional language) performance checks have to be done by some means or other. As rule of thumb the number of queries placed on the backend should be finite on each user interaction, i.e. no queries in a loop. If you follow this rule reasonable indices and the optimizer can do their job usually. >> Of course, if you are stuck with an SQL DB for some reason and you need >> to adapt to an OO application layer ORM might be a choice. But if the >> data model in the DB is not intended for ORM usage, you won't get happy, >> because there are almost always properties of the data model that are >> not correctly modeled in SQL. > > It seems as if very large parts of the Java, .NET and Ruby worlds > are able to make it work. There is always a way (with unlimited resources :-) ). But the question is about maintainability and TCO. And the answer is not always clear. Even small bugs or missing features in the ORM layer may result in fragile workarounds that collapse on small code changes. I would prefer when the investigation of standards around NoSQL over driving ORM to the limits. The first has a future, the latter is an intermediate solution. Of course, both have their places for now. Marcel
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2014-01-03 21:35 -0500 |
| Message-ID | <52c7738b$0$297$14726298@news.sunsite.dk> |
| In reply to | #27148 |
On 12/31/2013 5:12 AM, Marcel Müller wrote: > On 30.12.13 05.17, Arne Vajhøj wrote: >>> You see, I am not really a friend of ORM. If a relational data model >>> does not fit your needs, you first should consider to use a non >>> relational database, rather than to normalize the data model to fit into >>> a relational DB, and use an ORM to hide that from the application layer. >> >> Yes and no. >> >> If you could get non-relational databases with same transactional >> support, same tools, same vendor support etc.. >> >> And if all access to the database is OO based. >> >> Then that would be obvious. >> >> But the non-relational databases has not reached the same maturity level >> (as a summary term for the above) as relational databases. > > You are right. We are in an intermediate situation where relational DBMS > are integrated into backup, service and management processes by far > better than the new OO or document based DBMS. And of course, the > administrators have experience with them. > Because of this I did the last larger project still with MSSQL (in > snapshot isolation mode). But the data model did not depend on the DB. I > simply store XML documents with revision information. In fact the DBMS > backend was activated about 4 month after the project started. So when > the time is come we could easily move to Mongo or whatever. XML in either XML or CLOB columns is one way to combine the operational advantages of the RDBMS with a NoSQL approach to data. But you will still lack in tools support. No support from reporting software. And no tools for adhoc work - you will need to code everything. > What I miss by far more is a standard, how to use NoSQL DBMS. So anybody > writes its own framework with its own advantages and disadvantages. It is rather chaotic now. Many incompatible libraries. And some of the libraries are of bad quality. There are some attempts to remedy that in the Java world. Many JPA providers are starting to support NoSQL databases. Even though JPA is intended as an ORM then it can be made to work with NoSQL databases as well. And it is a standardized API. MS could do the same with EF if they wanted to. >> And it is common to have the same databases used by modern OO based >> software also to be used by non-OO legacy software (like 20 year >> old COBOL programs). > > COBOL, dark chapter - from the present point of view. And SAP extended > the COBOL style by ABAP. Legacy stuff is a reality whether we like it or not. > [performance] >> It should be mandatory for developers writing code using ORM to do some >> testing with the logging of actual SQL statements executed turned on. It >> reveals what is going on without having to know so much about the inside >> of the ORM. > > Well, true, but from the programmers point of view, I do not always want > to go that deep into the framework. This is like digging down to the > assembler level in former times. > However, at least when doing function programming (without a functional > language) performance checks have to be done by some means or other. As > rule of thumb the number of queries placed on the backend should be > finite on each user interaction, i.e. no queries in a loop. If you > follow this rule reasonable indices and the optimizer can do their job > usually. It is like many other things. One write some readable code. If performance test shows a real performance problem then one investigate. If one is using an ORM, then checking what SQL it generates is an obvious first step. >>> Of course, if you are stuck with an SQL DB for some reason and you need >>> to adapt to an OO application layer ORM might be a choice. But if the >>> data model in the DB is not intended for ORM usage, you won't get happy, >>> because there are almost always properties of the data model that are >>> not correctly modeled in SQL. >> >> It seems as if very large parts of the Java, .NET and Ruby worlds >> are able to make it work. > > There is always a way (with unlimited resources :-) ). But the question > is about maintainability and TCO. And the answer is not always clear. > Even small bugs or missing features in the ORM layer may result in > fragile workarounds that collapse on small code changes. > > I would prefer when the investigation of standards around NoSQL over > driving ORM to the limits. The first has a future, the latter is an > intermediate solution. Of course, both have their places for now. I doubt that relational databases will go away. Arne
[toc] | [prev] | [next] | [standalone]
| From | Marcel Müller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2014-01-06 22:19 +0100 |
| Message-ID | <52cb1dd0$0$9507$9b4e6d93@newsspool1.arcor-online.net> |
| In reply to | #27224 |
On 04.01.14 03.35, Arne Vajhøj wrote: > XML in either XML or CLOB columns is one way to combine the operational > advantages of the RDBMS with a NoSQL approach to data. > > But you will still lack in tools support. No support from reporting > software. And no tools for adhoc work - you will need to code everything. It's not that bad anymore. E.g. MSSQL supports xpath in queries (AFAIK since 2008) and you can also create indices based on xpath expressions. But there are restrictions. In fact I did not use this features in production so far. >> What I miss by far more is a standard, how to use NoSQL DBMS. So anybody >> writes its own framework with its own advantages and disadvantages. > > It is rather chaotic now. Many incompatible libraries. And some of the > libraries are of bad quality. Ack. > There are some attempts to remedy that in the Java world. Many > JPA providers are starting to support NoSQL databases. > > Even though JPA is intended as an ORM then it can be made to work > with NoSQL databases as well. > > And it is a standardized API. Maybe this is a start. > MS could do the same with EF if they wanted to. Uh, I did not recover from EF 3.5 so far. Never touched EF since that. For my taste it is bound to tight to MSSQL. >> [performance] > It is like many other things. > > One write some readable code. > > If performance test shows a real performance problem then one > investigate. Unfortunately this always tends to end up in the situation that the program consumes all available resources regardless of the complexity of the requirement. And even slight changes of the requirement maybe only small configuration changes bring the time bomb to explode. Not that pretty. I just had such a case today. 1.5E5 rows input, 2E4 rows out, now 5E4 rows out, n full table scans => O(n²), reduced locality, reduced cache efficiency, boom! 1 hour -> 24 hours. The optimization has not been done so far, but I would wonder if it will take more than a few minutes after completion. Programs like this mainly produce CO2. > If one is using an ORM, then checking what SQL it generates is > an obvious first step. Yes. I think you won't come around this for now. >> I would prefer when the investigation of standards around NoSQL over >> driving ORM to the limits. The first has a future, the latter is an >> intermediate solution. Of course, both have their places for now. > > I doubt that relational databases will go away. I agree. They will at least live as long as the large code base that rely on that. But the question is what are the future developments of SQL? And maybe at some point we will find SQL emulators based on NoSQL backends. So to speak the reciprocal of ORM. ;-) Marcel
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2014-01-07 23:33 -0400 |
| Message-ID | <8G3zu.222853$O25.93832@fx21.iad> |
| In reply to | #27247 |
On 01/06/2014 05:19 PM, Marcel Müller wrote: > On 04.01.14 03.35, Arne Vajhøj wrote: [ Total SNIP ] All this discussion indicates that what we do is seriously complex. :-) 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 | leif.roar@invalid.com (Leif Roar Moldskred) |
|---|---|
| Date | 2014-01-08 00:37 -0600 |
| Message-ID | <h-idnW9Jtdilb1HPnZ2dnUVZ8vidnZ2d@giganews.com> |
| In reply to | #27253 |
Arved Sandstrom <asandstrom2@eastlink.ca> wrote: > > All this discussion indicates that what we do is seriously complex. :-) > And if it isn't complex already, we'll gosh darned it _make_ it complex! (But mostly it actually is complex. Mostly.) -- Leif Roar Moldskred
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2013-12-30 17:03 -0400 |
| Message-ID | <Pclwu.107633$Rt7.104415@fx27.iad> |
| In reply to | #27052 |
On 12/22/2013 05:26 PM, Marcel Müller wrote: > On 22.12.13 20.05, Daniel Pitts wrote: >> This is cross-posted to cl.java.programmer and cl.php. > > The topic is unlikely to fit to php. F'up to java only. > >> 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. > > First of all you need to mention what ORMs are designed for. They are > intended to make SQL databases suitable for OO programming style and/or > non-relational data models. At the end OO expressions are turned into > SQL and then to an execution plan. Do ORMs "make SQL databases suitable for OO programming style"? In the sense that an ORM presents tuples derived from RDBMS data as OO programming language objects, that's true. But those initial datalayer objects are frequently PODSs, or very close, and a number of OO styles advocate keeping datalayer objects as essentially bundles of fields with accessor methods. As to the other main function of an ORM, which is to present a supposedly simpler way of accessing an RDBMS than JDBC, I think it's arguable as to whether any of that exemplifies high levels of the OO art: most of it (not just in Java) looks pretty procedural to me. > From that you can see that there is exactly one thing superfluous in > this scenario: SQL. It is the bottleneck where all expressions must fit > to. But it does not add any functionality, quite the contrary. It is > just a emulation level for compatibility, like a SATA adapter enables a > SATA drive to be used with an IDE port. > > You see, I am not really a friend of ORM. If a relational data model > does not fit your needs, you first should consider to use a non > relational database, rather than to normalize the data model to fit into > a relational DB, and use an ORM to hide that from the application layer. I'll posit that a relational data model does very often fit. We've just had a few generational cycles of young bucks who are trying to make their name by challenging something that works. Use a non-relational model when you've knowingly proved that there is no way of making your data fit relational - don't jump on non-relational because it's currently cool. > ORMs are known to slow things down. I don't think that this is true in > general. Err, if it's not true in general, then it's maybe not usually true? So it's "known" by whom? But the ORM layer makes some trivial looking expressions > amazingly complex. So it is not that easy for the programmer to estimate > the complexity of a code block, without knowledge about the entire ORM > layer and the base data model in SQL. In fact I have redesigned many > code parts because of this. That's why they pay us professional programmers big bucks. Simplifying complex when the complex can be simplified. I've rarely seen ORM code get more complex than NoSQL, ISAM/VSAM, or direct flat file operations. Unless a programmer is getting cute, or is incompetent. > 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. Good luck with that: I've seen a few recent startups fail because they thought that. > Of course, if you are stuck with an SQL DB for some reason and you need > to adapt to an OO application layer ORM might be a choice. But if the > data model in the DB is not intended for ORM usage, you won't get happy, > because there are almost always properties of the data model that are > not correctly modeled in SQL. > And most people who seize on a NoSQL solution were probably never "stuck" with an SQL DB, they just got sucked in by the hype. I've heard way more stories about projects where folks had to program relational-like logic on top of a NoSQL DB to solve their problems than I've heard anecdotes about people not being able to make things work with an RDBMS. > However, to get more detailed information you need to phrase your > questions more precisely. What are your topics of interest? Performance? > Maintainability? What kind of data model do you intend to use? Many > entities? Or many properties? What kind of relations? Polymorphism? > > > Marcel 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 | Marcel Müller <news.5.maazl@spamgourmet.org> |
|---|---|
| Date | 2013-12-31 15:30 +0100 |
| Message-ID | <52c2d520$0$6552$9b4e6d93@newsspool4.arcor-online.net> |
| In reply to | #27134 |
On 30.12.13 22.03, Arved Sandstrom wrote: >> First of all you need to mention what ORMs are designed for. They are >> intended to make SQL databases suitable for OO programming style and/or >> non-relational data models. At the end OO expressions are turned into >> SQL and then to an execution plan. > > Do ORMs "make SQL databases suitable for OO programming style"? In the > sense that an ORM presents tuples derived from RDBMS data as OO > programming language objects, that's true. But those initial datalayer > objects are frequently PODSs, or very close, and a number of OO styles > advocate keeping datalayer objects as essentially bundles of fields with > accessor methods. If I use ORM I expect that it can reasonably deal with deep structures. Normalizing the data model at object level is exactly not what I want. > As to the other main function of an ORM, which is to present a > supposedly simpler way of accessing an RDBMS than JDBC, I think it's > arguable as to whether any of that exemplifies high levels of the OO > art: most of it (not just in Java) looks pretty procedural to me. Hmm, you see ORM not as a function extension but simply as a more convenient API to RDBMS. That's OK. But maybe _O_RM does not hit the nail on the head in this case. >> You see, I am not really a friend of ORM. If a relational data model >> does not fit your needs, you first should consider to use a non >> relational database, rather than to normalize the data model to fit into >> a relational DB, and use an ORM to hide that from the application layer. > > I'll posit that a relational data model does very often fit. Well, maybe it fits because we mostly think in solutions rather than in requirements. This applies already to the customer requests. It is often difficult to distinguish between real requirements and creative ideas of the customer, how to solve his issues. If you get two steps back, then there are quite often requirements that do not fit well into RDBMS. I.e. I had almost no project where not at least one property of some object had a 1:n relation. I do not talk about classical relations like costomer-supplier here - they fit well into RDBMS. I talk about properties that can have more than one value. Case #1: enumeration types with multiple selections. To put them into a RDBMS you need either a) introduce a new table, b) serialize them into a string or bit vector or c) put each value into a separate column. Each choice has it's disadvantages. a) adds complexity to SQL (many JOINs, difficult updates - OK, here ORMs can really help) and has a large overhead for small integral types, because of the foreign keys and the row management of the DBMS. c) and b) only works if the number of different values is finite by design. b) cannot be reasonably indexed. c) makes it really complicated to add a new value. Within a OO data model I simply add an array or a set to the class and I am done. Case #2: multiple values without a limited set (e.g ingredients, allergens) Here can only use solution a) from above in the RDBMS. If you have a dozen properties of this type things get really worse. Or you end up with d) a transposed data model. But d) is even worse with respect to indices and does not provide type safety because the RDBMS can't handle polymorphism directly. I also have seen solutions with e) one transposed table for each data type. Now the RDBMS is finally raped. > We've just > had a few generational cycles of young bucks who are trying to make > their name by challenging something that works. Use a non-relational > model when you've knowingly proved that there is no way of making your > data fit relational - don't jump on non-relational because it's > currently cool. Of course, that's always true. But from my experience success is not manly a question whether you have gone one way or the other. It is more a question if you have done this well and in you have enough experience with the tools you are using. >> ORMs are known to slow things down. I don't think that this is true in >> general. > > Err, if it's not true in general, then it's maybe not usually true? So > it's "known" by whom? I think, I used the wrong wording. Let's call it a preconception. >> 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. >> Of course, if you are stuck with an SQL DB for some reason and you need >> to adapt to an OO application layer ORM might be a choice. But if the >> data model in the DB is not intended for ORM usage, you won't get happy, >> because there are almost always properties of the data model that are >> not correctly modeled in SQL. > > And most people who seize on a NoSQL solution were probably never > "stuck" with an SQL DB, they just got sucked in by the hype. I've heard > way more stories about projects where folks had to program > relational-like logic on top of a NoSQL DB to solve their problems than > I've heard anecdotes about people not being able to make things work > with an RDBMS. 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. Marcel
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom2@eastlink.ca> |
|---|---|
| Date | 2014-01-02 03:57 -0400 |
| Message-ID | <IZ8xu.72382$2R1.41666@fx13.iad> |
| In reply to | #27152 |
On 12/31/2013 10:30 AM, Marcel Müller wrote: > On 30.12.13 22.03, Arved Sandstrom wrote: >>> First of all you need to mention what ORMs are designed for. They are >>> intended to make SQL databases suitable for OO programming style and/or >>> non-relational data models. At the end OO expressions are turned into >>> SQL and then to an execution plan. >> >> Do ORMs "make SQL databases suitable for OO programming style"? In the >> sense that an ORM presents tuples derived from RDBMS data as OO >> programming language objects, that's true. But those initial datalayer >> objects are frequently PODSs, or very close, and a number of OO styles >> advocate keeping datalayer objects as essentially bundles of fields with >> accessor methods. > > If I use ORM I expect that it can reasonably deal with deep structures. > Normalizing the data model at object level is exactly not what I want. 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. >> As to the other main function of an ORM, which is to present a >> supposedly simpler way of accessing an RDBMS than JDBC, I think it's >> arguable as to whether any of that exemplifies high levels of the OO >> art: most of it (not just in Java) looks pretty procedural to me. > > Hmm, you see ORM not as a function extension but simply as a more > convenient API to RDBMS. That's OK. But maybe _O_RM does not hit the > nail on the head in this case. Marcel, I've never thought that ORM (_O_RM as you emphasize it) precisely hits the nail on the head. You did hit the nail on the head when you described you I view ORMs: I see them as providing more convenient access to databases. I also believe that they are usually better than other models. >>> You see, I am not really a friend of ORM. If a relational data model >>> does not fit your needs, you first should consider to use a non >>> relational database, rather than to normalize the data model to fit into >>> a relational DB, and use an ORM to hide that from the application layer. >> >> I'll posit that a relational data model does very often fit. > > Well, maybe it fits because we mostly think in solutions rather than in > requirements. This applies already to the customer requests. It is often > difficult to distinguish between real requirements and creative ideas of > the customer, how to solve his issues. Marcel, if you come up with an answer to us developers mostly thinking about solutions, I applaud you. :-) I've been programming since my late teens, back in the '70's, and in my experience IT people almost invariably choose what they know: there are financial reasons for doing that, career reasons for doing that, and "I don't know about the other possibilities" reasons for doing that. Speaking to that last point, Marcel, if you can do better than the rest of us at figuring out how many "solutions" there are, I commend you. [ SNIP ] > >> We've just >> had a few generational cycles of young bucks who are trying to make >> their name by challenging something that works. Use a non-relational >> model when you've knowingly proved that there is no way of making your >> data fit relational - don't jump on non-relational because it's >> currently cool. > > Of course, that's always true. > > But from my experience success is not manly a question whether you have > gone one way or the other. It is more a question if you have done this > well and in you have enough experience with the tools you are using. > In a way you are proving my point, per your last sentence. Good or great coders make things work; they do even better if they have experience with the technology. There aren't that many superlative IT technologies out there, although there are many that are OK, and even more that are bad. A competent experienced developer can work with bad stuff and still produce solutions; a poor developer can use excellent software and fail. By the way, before you tackle a project involving the combination of IBM, Oracle, and SAP software, consider suicide. I don't think any amount of experience helps with that. [ SNIP ] > >>> 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. > May I act as the child who called out the emperor for being naked? :-) Tim Bray, who we all know, has made comments like this: "Whether you like XML or not, we’re stuck with it for a long time. These days, the only new XML-based projects being started up are document-centric and publishing-oriented. Thank goodness, because that’s a much better fit than all the WS-* and Java EE config puke and so on that has given those three letters a bad name among so many programmers. XML for your document database is actually pretty hard to improve on." "When XML was invented, it was the world’s only useful cross-platform cross-language cross-character-set cross-database data format. Where by “useful” I mean, “came with a pretty good suite of free open-source tools to do the basic things you needed.” ¶ That’s why it ended up being used for all sorts of wildly-inappropriate things." "That I gave up working on Lark, the first ever production-ready XML parser, and still one of the fastest. It was maybe the best piece of software I ever wrote; but I couldn’t see the point when there were two other pretty good Java-language XML parsers out there in the wild. Oh well." And Tim made a bit of a masturbatory blog post here: http://www.tbray.org/ongoing/When/200x/2006/04/18/XML-Grammar. Point being, one of the authors of XML is a bit confused about XML. He's changed his views about it frequently. I've met the man; I even had the privilege of him telling me back in 1999 or so that indexing and searching XML was stupid. XML is about as well-structured as the thoughts of the author, Marcel. It's also not really a wonderful means for describing data or documents, although Bray is in love with it. A structured flat file is better. As to that first paragraph I quoted, it's a good thing that Tim is 6 years older than me, and will soon retire. "WS-* and Java EE config puke"? The man has not ever seriously engaged in SOA, or J2EE/Java EE, but he's happy to deliver opinions like that. He's an idiot. >>> Of course, if you are stuck with an SQL DB for some reason and you need >>> to adapt to an OO application layer ORM might be a choice. But if the >>> data model in the DB is not intended for ORM usage, you won't get happy, >>> because there are almost always properties of the data model that are >>> not correctly modeled in SQL. >> >> And most people who seize on a NoSQL solution were probably never >> "stuck" with an SQL DB, they just got sucked in by the hype. I've heard >> way more stories about projects where folks had to program >> relational-like logic on top of a NoSQL DB to solve their problems than >> I've heard anecdotes about people not being able to make things work >> with an RDBMS. > > 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. > > > Marcel Silvio made some similar points, related to in-memory, the importance of language objects, and performance. You've added some extra observations. Call me dubious about most of the points, however. Most people have recognized the limitations of NoSQL: CouchDB and Mongo were sexy, but they are limited. Amazon recognizes that NoSQL is limited, maybe the rest of us should. I'm wondering about what exactly we are arguing about, though, Marcel. Referring to a paragraph of yours, I have myself seen people program relational-type logic on top of NoSQL datastores: this almost invariably happens. I've also heard about programmers who can't make things work with an RDBMS - you usually fire them. With all due respect, I'll call bullshit about "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." That's highly implausible. 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]
Page 3 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