Thread: [htmltmpl] eWeek Reviews Bricolage
Brought to you by:
samtregar
Menu
▾
▴
html-template-users
|
From: David W. <da...@ki...> - 2004-08-10 19:48:27
Attachments:
smime.p7s
|
eWeek has reviewed Bricolage, the mod_perl-powered, HTML::Template-supporting, PostgreSQL-backed open-source content management system. The article was published last week. An excerpt: > Bricolage is quite possibly the most capable enterprise-class > open-source application available. The Web content management > application features excellent administration capabilities, and it is > highly extensible and capable of managing even the biggest and most > complex Web sites. As an open-source product, Bricolage is free, and > companies can now purchase support and development services from > Kineticode. http://www.eweek.com/article2/0,1759,1627959,00.asp The article is part of the "Content Management Face-Off" in the current issue of eWeek: > Included in this evaluation are the open-source Bricolage 1.8.1, > Interwoven Inc.'s TeamSite 6.1, CrownPeak Technology Inc.'s Advantage > CMS, Serena Software Inc.'s Collage 4.5, PaperThin Inc.'s CommonSpot > Content Server 4.0 and Ektron Inc.'s CMS300 4.5. (The reviews are > ordered, roughly, from the high end to the low end of the content > management market.) http://www.eweek.com/article2/0,1759,1627957,00.asp Regards, David |
|
From: Sam T. <sa...@tr...> - 2004-08-10 20:50:43
|
On Tue, 10 Aug 2004, David Wheeler wrote: > eWeek has reviewed Bricolage, the mod_perl-powered, > HTML::Template-supporting, PostgreSQL-backed open-source content > management system. The article was published last week. An excerpt: And if you like the sound of Bricolage, you're gonna really like Krang! Not only does it also support HTML::Template, it was built with HTML::Template. Check it out: http://krang.sf.net Here's a comparison of Krang and an older version of Bricolage: http://krang.sf.net/docs/krang_vs_bric.html -sam PS: Yup, this is still my list. ;) |
|
From: David W. <da...@ki...> - 2004-08-11 15:38:43
Attachments:
smime.p7s
|
On Aug 10, 2004, at 1:50 PM, Sam Tregar wrote: > Here's a comparison of Krang and an older version of Bricolage: > > http://krang.sf.net/docs/krang_vs_bric.html Make that an _ancient_ version of Bricolage. So ancient that the comparison is far from accurate and no longer really relevant. Cheers, David |
|
From: Sam T. <sa...@tr...> - 2004-08-11 16:05:25
|
On Wed, 11 Aug 2004, David Wheeler wrote: > On Aug 10, 2004, at 1:50 PM, Sam Tregar wrote: > > > Here's a comparison of Krang and an older version of Bricolage: > > > > http://krang.sf.net/docs/krang_vs_bric.html > > Make that an _ancient_ version of Bricolage. So ancient that the > comparison is far from accurate and no longer really relevant. Patches welcome. It's a pretty old version of Krang too, actually! -sam |
|
From: Robert <ca...@li...> - 2004-08-11 17:30:18
|
"Sam Tregar" <sa...@tr...> wrote in message news:Pin...@hi...... > On Wed, 11 Aug 2004, David Wheeler wrote: > > > On Aug 10, 2004, at 1:50 PM, Sam Tregar wrote: > > > > > Here's a comparison of Krang and an older version of Bricolage: > > > > > > http://krang.sf.net/docs/krang_vs_bric.html > > > > Make that an _ancient_ version of Bricolage. So ancient that the > > comparison is far from accurate and no longer really relevant. > > Patches welcome. It's a pretty old version of Krang too, actually! > > -sam > I noticed a couple of things from the site. I don't see it working on Windows using Apache? Is this possible? Also it seems to be MySQL specific. Did I read that wrong? Robert |
|
From: Sam T. <sa...@tr...> - 2004-08-11 22:56:09
|
On Wed, 11 Aug 2004, Robert wrote: > I noticed a couple of things from the site. I don't see it working on > Windows using Apache? Is this possible? Yes, and of course. Very little software written for Unix-esque systems (like Krang and Bricolage) works on Windows. I don't see any reason why it couldn't be made to work on Windows, but I see very little reason to do so! > Also it seems to be MySQL specific. Did I read that wrong? Nope, you got that right too. -sam |
|
From: Chisel W. <ch...@he...> - 2004-08-11 23:22:45
|
On Wed, Aug 11, 2004 at 06:56:08PM -0400, Sam Tregar wrote: > > Also it seems to be MySQL specific. Did I read that wrong? > > Nope, you got that right too. Out of interest, why MySQL? I know that lack of Postgres support is one reason that we didn't consider Krang recently when looking for a content management system recently. Not trying to start a flame-war. Were there technical reasons, or was it a "I have time to make it work well with on database" thing? Chisel -- e: ch...@he... | Opinions are like arseholes - w: http://www.herlpacker.co.uk/ | everyone has one gpg: D167E7FE | |
|
From: Peter L. <pe...@pe...> - 2004-08-12 00:49:37
|
On Thu, 12 Aug 2004, Chisel Wright wrote: > On Wed, Aug 11, 2004 at 06:56:08PM -0400, Sam Tregar wrote: >>> Also it seems to be MySQL specific. Did I read that wrong? >> >> Nope, you got that right too. > > Out of interest, why MySQL? I know that lack of Postgres support is one > reason that we didn't consider Krang recently when looking for a content > management system recently. Really? Can you explain why MySQL vs. Postgres was a deal-breaker? And out of curiosity, what were the other reasons? Since noone chooses a CMS lightly (it really is a long-term decision), I'd really love to know. Besides, we're always looking for ways to improve Krang! > > Not trying to start a flame-war. Were there technical reasons, or was it > a "I have time to make it work well with on database" thing? > Phew. And to quell any thoughts in the wings, yes, you can work on Krang in both emacs and vi. Or any other editor for that matter (yes, nano folks too!). Simply put, we started developing Krang to serve our own needs, and MySQL fit our needs better than Postgres did. We open-sourced it as a way to give back to the community, and if people want support for other DB's, they're welcome to contribute. :) |
|
From: Sam T. <sa...@tr...> - 2004-08-12 04:04:29
|
On Thu, 12 Aug 2004, Chisel Wright wrote:
> On Wed, Aug 11, 2004 at 06:56:08PM -0400, Sam Tregar wrote:
> > > Also it seems to be MySQL specific. Did I read that wrong?
> >
> > Nope, you got that right too.
>
> Out of interest, why MySQL? I know that lack of Postgres support is one
> reason that we didn't consider Krang recently when looking for a content
> management system recently.
That's too bad. I'm not sure why you'd care which database your
content-management system was running on. In most cases you'll hardly
notice unless it breaks, and I'd warrant that MySQL is a heck of a lot
less likely to break than PostgreSQL!
> Were there technical reasons
MySQL is, in my opinion, the best free database. It's definitely
better than PostgreSQL and I should know, I spent more than a year and
a half working with it on the Bricolage project. Of course, how one
defines "better" is subjective. Here are a few observations that come
to mind:
- MySQL is more stable. The developers of MySQL do an absolutely
amazing job vetting new releases before they're declared stable.
I encountered exactly one bug in MySQL while developing Krang.
Just one! I don't have enough fingers to count all the bugs I saw
in PostgreSQL while working on Bricolage.
- MySQL is faster and easier to optimize when it's running slow.
Indexes just work 99% of the time, unlike PostgreSQL's lame VACUUM
ANALYZE run-around.
- MySQL is easier to master and harder to abuse. The set of
supported commands is much smaller than most databases. That
means it's harder to end up with a rat's nest of a database
schema. Harder, but of course not impossible!
Now, to be fair, PostgreSQL has a lot of features that aren't present
in MySQL. I tend to think most of them aren't all they're cracked up
to be, but I understand that a reasonable person can disagree.
> or was it a "I have time to make it work well with on database"
> thing?
Sure, that too. My constant refrain while I led the Krang's
development was "YAGNI" - You Ain't Gonna Need It. We definitely
didn't need to support more than one DB, so we didn't. If someone
wants to come along and add PostgreSQL support, I think that's fine.
I think it's about as likely as someone porting Bricolage to MySQL,
but people talk about that all the time too!
-sam
|
|
From: Mathew R. <mat...@re...> - 2004-08-12 04:29:28
|
you are kidding right? ACID capabilites and all that... proper locking semantics... long history with native support for transactions... proper SQL transaction semantics... As you said, people can make spaghetti out of anything - how this makes = MySQL 'better', I dont understand. Mathew > > > > Also it seems to be MySQL specific. Did I read that wrong? > > >=20 > > > Nope, you got that right too. > >=20 > > Out of interest, why MySQL? I know that lack of Postgres support is = one > > reason that we didn't consider Krang recently when looking for a = content > > management system recently. >=20 > That's too bad. I'm not sure why you'd care which database your > content-management system was running on. In most cases you'll hardly > notice unless it breaks, and I'd warrant that MySQL is a heck of a lot > less likely to break than PostgreSQL! >=20 > > Were there technical reasons >=20 > MySQL is, in my opinion, the best free database. It's definitely > better than PostgreSQL and I should know, I spent more than a year and > a half working with it on the Bricolage project. Of course, how one > defines "better" is subjective. Here are a few observations that come > to mind: >=20 > - MySQL is more stable. The developers of MySQL do an absolutely > amazing job vetting new releases before they're declared stable. > I encountered exactly one bug in MySQL while developing Krang. > Just one! I don't have enough fingers to count all the bugs I saw > in PostgreSQL while working on Bricolage. >=20 > - MySQL is faster and easier to optimize when it's running slow. > Indexes just work 99% of the time, unlike PostgreSQL's lame VACUUM > ANALYZE run-around. >=20 > - MySQL is easier to master and harder to abuse. The set of > supported commands is much smaller than most databases. That > means it's harder to end up with a rat's nest of a database > schema. Harder, but of course not impossible! >=20 > Now, to be fair, PostgreSQL has a lot of features that aren't present > in MySQL. I tend to think most of them aren't all they're cracked up > to be, but I understand that a reasonable person can disagree. >=20 > > or was it a "I have time to make it work well with on database" > > thing? >=20 > Sure, that too. My constant refrain while I led the Krang's > development was "YAGNI" - You Ain't Gonna Need It. We definitely > didn't need to support more than one DB, so we didn't. If someone > wants to come along and add PostgreSQL support, I think that's fine. > I think it's about as likely as someone porting Bricolage to MySQL, > but people talk about that all the time too! >=20 > -sam |
|
From: Sam T. <sa...@tr...> - 2004-08-12 04:50:17
|
On Thu, 12 Aug 2004, Mathew Robertson wrote: > you are kidding right? Not at all. That doesn't mean I expect to convince anyone though. This is the kind of wisdom that usually only comes from experience! > ACID capabilites and all that... > proper locking semantics... > long history with native support for transactions... > proper SQL transaction semantics... Over-rated. Sure, if I was building banking software I might have a different opinion, but I'm not. A simple database with few critical bugs protects my data better than your fancy ACID transactions! How can I be so sure? I've worked with big complex systems running on both databases. I've watched Bricolage completely destroy user data despite using PostgreSQL's transaction support. In contrast, Krang hasn't lost data yet, as far as I know. A few careful locks in the right places seem to be just what the doctor ordered for a moderatly complex content management system. And if the catastrophic happens, like a system crash, that's what nightly backups are for. Nightly backups might not be good enough for all applications, but they're good enough for a content-management system. > As you said, people can make spaghetti out of anything - how this > makes MySQL 'better', I dont understand. Experience. Wrestle with a database strewn with triggers, constraints, abstract types and functions sometime. You'll be begging to be back in the moderate mess of a badly designed MySQL DB. There's less there so there's just less to do badly. It may not be an emperical fact, but I didn't presented it as such! -sam |
|
From: David W. <da...@ki...> - 2004-08-12 05:01:20
Attachments:
smime.p7s
|
On Aug 11, 2004, at 9:50 PM, Sam Tregar wrote: > How can I be so sure? I've worked with big complex systems running on > both databases. I've watched Bricolage completely destroy user data > despite using PostgreSQL's transaction support. You did? Why was there never a bug report? I have not seen Bricolage lose data. > In contrast, Krang > hasn't lost data yet, as far as I know. A few careful locks in the > right places seem to be just what the doctor ordered for a moderatly > complex content management system. And if the catastrophic happens, > like a system crash, that's what nightly backups are for. Nightly > backups might not be good enough for all applications, but they're > good enough for a content-management system. Well, I think I'll just let that comment stand for itself. > Experience. Wrestle with a database strewn with triggers, > constraints, abstract types and functions sometime. You'll be begging > to be back in the moderate mess of a badly designed MySQL DB. There's > less there so there's just less to do badly. It may not be an > emperical fact, but I didn't presented it as such! But this is typical of the difference between a software developer and a DBA. I think that one of the main reasons that MySQL is so popular is that developers like it, because they don't have to think about DBA issues. Hrm, I could say more, but we're pretty off-topic here. I'll hold my tongue now. Cheers, David |
|
From: Sam T. <sa...@tr...> - 2004-08-12 05:51:46
|
On Wed, 11 Aug 2004, David Wheeler wrote: > On Aug 11, 2004, at 9:50 PM, Sam Tregar wrote: > > > How can I be so sure? I've worked with big complex systems running on > > both databases. I've watched Bricolage completely destroy user data > > despite using PostgreSQL's transaction support. > > You did? Why was there never a bug report? I have not seen Bricolage lose > data. You must be blessed. There's a whole class of data-loss bugs that I know I reported but neither of us could replicate. Once we decided that 1.4.6 was our last upgrade it seemed like a waste of your time to keep bugging you. A good example would be stories that can no longer be edited or published because they've got NULL element__id pointers. How did they get NULL element__ids? I have no idea. I've never been able to make it happen on my own. But I know it happens because I've had to go in and nuke them every so often to get the system publishing again. Similar bugs occur with less frequency in the media and category systems. Seemingly for no reason at all an object will lose a critical ID, often in the morass of the member table. Generally the only thing to do is to delete it and ask the user to re-enter the data. Sometimes it's possible to intuit the missing ID, but that's definitely not the average case. My point wasn't to slander Bricolage, just to provide a case where transactions didn't do much to protect critical data. In my experience they're just a tool which can help in unusual circumstances. They're no replacement for careful coding and testing. > > Experience. Wrestle with a database strewn with triggers, > > constraints, abstract types and functions sometime. You'll be begging > > to be back in the moderate mess of a badly designed MySQL DB. There's > > less there so there's just less to do badly. It may not be an > > emperical fact, but I didn't presented it as such! > > But this is typical of the difference between a software developer and a DBA. > I think that one of the main reasons that MySQL is so popular is that > developers like it, because they don't have to think about DBA issues. Yeah, you got me. I'm a developer. I've never even met a DBA that I would trust to work on my data (but I haven't met many)! Maybe someday when I do I'll have to use the database he likes to work on. Until then, I choose! Would it make sense to have it any other way? -sam |
|
From: David W. <da...@ki...> - 2004-08-12 06:01:24
Attachments:
smime.p7s
|
On Aug 11, 2004, at 10:51 PM, Sam Tregar wrote: > You must be blessed. There's a whole class of data-loss bugs that I > know I reported but neither of us could replicate. Once we decided > that 1.4.6 was our last upgrade it seemed like a waste of your time to > keep bugging you. A good example would be stories that can no longer > be edited or published because they've got NULL element__id pointers. > How did they get NULL element__ids? I have no idea. I've never been > able to make it happen on my own. But I know it happens because I've > had to go in and nuke them every so often to get the system publishing > again. None of Kineticode's customers have reported this problem including PIRT. And there are several hundred thousand documents behind that, excluding PIRT. I guess you didn't report it because you couldn't replicate it. I remember you mentioning it, though. > Similar bugs occur with less frequency in the media and category > systems. Seemingly for no reason at all an object will lose a > critical ID, often in the morass of the member table. Generally the > only thing to do is to delete it and ask the user to re-enter the > data. Sometimes it's possible to intuit the missing ID, but that's > definitely not the average case. This often isn't possible, because the FK columns are NOT NULL. And again, I've only heard about this from you in email threads like this; no other Kineticode customer has ever reported a problem. > My point wasn't to slander Bricolage, just to provide a case where > transactions didn't do much to protect critical data. In my > experience they're just a tool which can help in unusual > circumstances. They're no replacement for careful coding and testing. Yes, well, transactions are no protection from buggy code, regardless of your database choice. So we're in agreement. But I've found having each Apache request constituting a transaction extremely helpful in minimizing data integrity problems. > Yeah, you got me. I'm a developer. I've never even met a DBA that I > would trust to work on my data (but I haven't met many)! Maybe > someday when I do I'll have to use the database he likes to work on. > Until then, I choose! Would it make sense to have it any other way? Yes, it makes sense to become a DBA, to a certain degree. Okay, no more OT missives from me! I need some sleep. Regards, David |
|
From: Sam T. <sa...@tr...> - 2004-08-12 06:13:25
|
On Wed, 11 Aug 2004, David Wheeler wrote: > None of Kineticode's customers have reported this problem including > PIRT. And there are several hundred thousand documents behind that, > excluding PIRT. I guess you didn't report it because you couldn't > replicate it. I remember you mentioning it, though. Yeah, I usually don't bother reporting bugs I can't replicate. That doesn't make them less real though! > This often isn't possible, because the FK columns are NOT NULL. And again, > I've only heard about this from you in email threads like this; no other > Kineticode customer has ever reported a problem. True. I didn't mean to imply that they always became NULL. In the case of the member table it's more common that the proper rows just cease to exist. Like a category will lose its category group member link (or whatever that thing is that all categories need one of or they stop working). -sam |
|
From: David W. <da...@ki...> - 2004-08-12 15:39:42
Attachments:
smime.p7s
|
On Aug 11, 2004, at 11:13 PM, Sam Tregar wrote: > True. I didn't mean to imply that they always became NULL. In the > case of the member table it's more common that the proper rows just > cease to exist. Like a category will lose its category group member > link (or whatever that thing is that all categories need one of or > they stop working). Sounds a bit mystical to me. ;-) Regards, David |
|
From: David W. <da...@ki...> - 2004-08-11 23:29:32
Attachments:
smime.p7s
|
On Aug 11, 2004, at 3:56 PM, Sam Tregar wrote: > Yes, and of course. Very little software written for Unix-esque > systems (like Krang and Bricolage) works on Windows. I don't see any > reason why it couldn't be made to work on Windows, but I see very > little reason to do so! I expect that Bricolage will be ported to Windows shortly after mod_perl 2 ships with robust thread support (which is unlikely in 2.0.0), especially now that PostgreSQL 8.0 will be Win32 native. Regards, David |
|
From: Sam T. <sa...@tr...> - 2004-08-12 02:10:00
|
On Wed, 11 Aug 2004, David Wheeler wrote: > I expect that Bricolage will be ported to Windows shortly after mod_perl 2 > ships with robust thread support (which is unlikely in 2.0.0), especially now > that PostgreSQL 8.0 will be Win32 native. Really? I wonder why anyone would bother! -sam |
|
From: David W. <da...@ki...> - 2004-08-12 04:52:52
Attachments:
smime.p7s
|
On Aug 11, 2004, at 7:09 PM, Sam Tregar wrote: >> I expect that Bricolage will be ported to Windows shortly after >> mod_perl 2 >> ships with robust thread support (which is unlikely in 2.0.0), >> especially now >> that PostgreSQL 8.0 will be Win32 native. > > Really? I wonder why anyone would bother! Ch-ching. ;-) Also, read the eWeek review. Regards, David -- David Wheeler President, Kineticode, Inc. http://www.kineticode.com/ Kineticode. Setting knowledge in motion.[sm] |
|
From: David W. <da...@ki...> - 2004-08-12 04:58:12
Attachments:
smime.p7s
|
On Aug 11, 2004, at 9:04 PM, Sam Tregar wrote: > MySQL is, in my opinion, the best free database. It's definitely > better than PostgreSQL and I should know, I spent more than a year and > a half working with it on the Bricolage project. Of course, how one > defines "better" is subjective. Here are a few observations that come > to mind: > > - MySQL is more stable. The developers of MySQL do an absolutely > amazing job vetting new releases before they're declared stable. > I encountered exactly one bug in MySQL while developing Krang. > Just one! I don't have enough fingers to count all the bugs I saw > in PostgreSQL while working on Bricolage. To whom did you report them? I don't recall you running into any bugs, only features you were used to in MySQL but were missing in PostgreSQL. > - MySQL is faster and easier to optimize when it's running slow. > Indexes just work 99% of the time, unlike PostgreSQL's lame VACUUM > ANALYZE run-around. Huh? This is because MySQL doesn't keep statistics, which long term is to its detriment. PostgreSQL 7.4 introduced pg_autovaucuum, and it is built-in to the server in 8.0, so now it's a no-brainer. > - MySQL is easier to master and harder to abuse. The set of > supported commands is much smaller than most databases. That > means it's harder to end up with a rat's nest of a database > schema. Harder, but of course not impossible! You also don't get any of the advantages of more advanced databases. > Now, to be fair, PostgreSQL has a lot of features that aren't present > in MySQL. I tend to think most of them aren't all they're cracked up > to be, but I understand that a reasonable person can disagree. Yep. But this is old hat for you and me, isn't it? ;-) > Sure, that too. My constant refrain while I led the Krang's > development was "YAGNI" - You Ain't Gonna Need It. We definitely > didn't need to support more than one DB, so we didn't. If someone > wants to come along and add PostgreSQL support, I think that's fine. > I think it's about as likely as someone porting Bricolage to MySQL, > but people talk about that all the time too! Hrm, so Krang has embedded SQL like Bricolage? Pity. I would certainly never do that again. Regards, David |
|
From: Sam T. <sa...@tr...> - 2004-08-12 05:33:57
|
On Wed, 11 Aug 2004, David Wheeler wrote:
> To whom did you report them? I don't recall you running into any bugs, only
> features you were used to in MySQL but were missing in PostgreSQL.
On the PostgreSQL mailing-list. Two that jump to mind which I'm
absolutely sure I reported:
- pg_dump produces invalid SQL.
- Indexes don't get used unless you VACUUM ANALYZE your tables. I'd
consider documenting this fact in the section on indexes, but it
would be even better if it would just go away.
If I remember correctly they both got scheduled to be fixed in some
future version. You could be right that I let some slip and just gave
up after finding workarounds. That sounds like me, unfortunately!
> > - MySQL is faster and easier to optimize when it's running slow.
> > Indexes just work 99% of the time, unlike PostgreSQL's lame VACUUM
> > ANALYZE run-around.
>
> Huh? This is because MySQL doesn't keep statistics, which long term is to its
> detriment.
Lies! MySQL certainly does keep statistics. It just doesn't require
them to get good use out of most out of its indexes.
> PostgreSQL 7.4 introduced pg_autovaucuum, and it is built-in to the
> server in 8.0, so now it's a no-brainer.
That's good. I didn't mean to imply that PostgreSQL isn't improving.
I just happen to think that MySQL is more stable at present, and that
it has been more stable in the past.
> > Now, to be fair, PostgreSQL has a lot of features that aren't present
> > in MySQL. I tend to think most of them aren't all they're cracked up
> > to be, but I understand that a reasonable person can disagree.
>
> Yep. But this is old hat for you and me, isn't it? ;-)
Sure is. I don't expect to convince anyone who has already made up
their mind. But if you ask me why I use MySQL then I don't mind
telling you! If you don't like my reasons, well, what can I do about
that?
> Hrm, so Krang has embedded SQL like Bricolage? Pity. I would
> certainly never do that again.
The API classes do. The CGI layer doesn't and neither do the scripts
in bin/. I find this to be a pretty reasonable setup and easy to
maintain, but I'm sure there are other reasonable ways to do it.
Actually, this was one of the more difficult design decisions I faced
in Krang. I spent a couple weeks evaluating OO DB wrappers
(Class::DBI, Alzabo, etc). Ultimately I decided that they weren't
solving any of the hard problems in Krang, but they would add another
layer of complexity. The results have been good, but I can't really
say with authority what the alternative would have been like.
Unlike MySQL vs. PostgreSQL. I've been there, I've done that and I
know the score! ;)
-sam
|
|
From: Mathew R. <mat...@re...> - 2004-08-12 05:14:35
|
> > you are kidding right? >=20 > Not at all. That doesn't mean I expect to convince anyone though. > This is the kind of wisdom that usually only comes from experience! I'll ignore that... > > ACID capabilites and all that... > > proper locking semantics... > > long history with native support for transactions... > > proper SQL transaction semantics... >=20 > Over-rated. Sure, if I was building banking software I might have a > different opinion, but I'm not. A simple database with few critical > bugs protects my data better than your fancy ACID transactions! :-) > How can I be so sure? I've worked with big complex systems running on > both databases. I've watched Bricolage completely destroy user data > despite using PostgreSQL's transaction support. In contrast, Krang > hasn't lost data yet, as far as I know. A few careful locks in the > right places seem to be just what the doctor ordered for a moderatly > complex content management system. And if the catastrophic happens, > like a system crash, that's what nightly backups are for. Nightly > backups might not be good enough for all applications, but they're > good enough for a content-management system. >=20 > > As you said, people can make spaghetti out of anything - how this > > makes MySQL 'better', I dont understand. >=20 > Experience. Wrestle with a database strewn with triggers, > constraints, abstract types and functions sometime. umm - yes, I do this already... the cluster I am currently involved in = building is meant to store 100+ billion records... see below... > You'll be begging > to be back in the moderate mess of a badly designed MySQL DB. There's > less there so there's just less to do badly. It may not be an > emperical fact, but I didn't presented it as such! My team is currently building a "Parallel query cluster" (eg "PARALLEL = hash(id) SELECT id,value FROM row_data WHERE some_clause"), such that we = are building the 'PARALLEL hash(...)' bit. The idea is that you have a cluster of say 100 nodes, with various = schema such a foreign keys, etc. Then you query it from you data = processing engine... ... given that I have been using databases since I left uni at 24 (I am = 31 now), I'd say that I have enough experience... We prefer Open Source tools (which is why we use H::T), high reliability = and high performance -> we chose PostgreSQL over Oracle; MySQL wasn't = even a consideration... In any case, I personally think that MySQL is good enough for most = tasks; and since this is a little off-thread for H::T, I'll now shut my = big fat trap... Mathew |
|
From: simran <sim...@re...> - 2004-08-12 05:34:09
|
I'm a
* start with postgres approx 1996
- it was out there and simple...
* migrated to mysql (for speed) approx 1998
- was gazillions of times faster than postgres
(postgres was slooow for the average transaction)
* migrated back to postgres approx 2000
- postgres improved vastly in speed (still not as quick as mysql
... but that is not its mission)
- supported constraints and most importantly triggers/foreign keys
... i can't live without foreign keys anymore... at all...
have numerous tables like:
- users (has primary key id)
- plugin developer develops "users_extended" (sets foreign key
to id with auto-update/delete cascading)
- plugin developer develops other table dependent on users (id)
- etc etc etc
If a user is deleted, all user data from all tables is deleted
(taken care of by database).
- This would just not be possible without foreign keys... the
application would *need to know* about any additional tables being
added and as such, the update/delete functions would need to be
updated in the core, making plugin development very cumbersome.
- Another fantastic feature is 'transactions'... can't say enough
good things about them :-)
If mysql is "better" because its smaller, why are they suddenly now
starting to support all these features, which no doubt will slow it down
(putting it on par with postgres)...
Horses for courses i say, but i *currently* like postgres much better
due to its feature set... which enables clean separation and programming
:-)
On Thu, 2004-08-12 at 15:14, Mathew Robertson wrote:
> > > you are kidding right?
> >
> > Not at all. That doesn't mean I expect to convince anyone though.
> > This is the kind of wisdom that usually only comes from experience!
>
> I'll ignore that...
>
> > > ACID capabilites and all that...
> > > proper locking semantics...
> > > long history with native support for transactions...
> > > proper SQL transaction semantics...
> >
> > Over-rated. Sure, if I was building banking software I might have a
> > different opinion, but I'm not. A simple database with few critical
> > bugs protects my data better than your fancy ACID transactions!
>
> :-)
>
> > How can I be so sure? I've worked with big complex systems running on
> > both databases. I've watched Bricolage completely destroy user data
> > despite using PostgreSQL's transaction support. In contrast, Krang
> > hasn't lost data yet, as far as I know. A few careful locks in the
> > right places seem to be just what the doctor ordered for a moderatly
> > complex content management system. And if the catastrophic happens,
> > like a system crash, that's what nightly backups are for. Nightly
> > backups might not be good enough for all applications, but they're
> > good enough for a content-management system.
> >
> > > As you said, people can make spaghetti out of anything - how this
> > > makes MySQL 'better', I dont understand.
> >
> > Experience. Wrestle with a database strewn with triggers,
> > constraints, abstract types and functions sometime.
>
> umm - yes, I do this already... the cluster I am currently involved in building is meant to store 100+ billion records... see below...
>
> > You'll be begging
> > to be back in the moderate mess of a badly designed MySQL DB. There's
> > less there so there's just less to do badly. It may not be an
> > emperical fact, but I didn't presented it as such!
>
> My team is currently building a "Parallel query cluster" (eg "PARALLEL hash(id) SELECT id,value FROM row_data WHERE some_clause"), such that we are building the 'PARALLEL hash(...)' bit.
>
> The idea is that you have a cluster of say 100 nodes, with various schema such a foreign keys, etc. Then you query it from you data processing engine...
>
> ... given that I have been using databases since I left uni at 24 (I am 31 now), I'd say that I have enough experience...
>
> We prefer Open Source tools (which is why we use H::T), high reliability and high performance -> we chose PostgreSQL over Oracle; MySQL wasn't even a consideration...
>
>
> In any case, I personally think that MySQL is good enough for most tasks; and since this is a little off-thread for H::T, I'll now shut my big fat trap...
>
> Mathew
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X