Re: Design Strategy WAS: High-Profile Advocacy Opportunity:VbulletinForum
От | Christopher Browne |
---|---|
Тема | Re: Design Strategy WAS: High-Profile Advocacy Opportunity:VbulletinForum |
Дата | |
Msg-id | m3wu1wto8q.fsf@wolfe.cbbrowne.com обсуждение исходный текст |
Ответ на | High-Profile Advocacy Opportunity: Vbulletin Forum Software ("Donnacha Mac Gloinn" <postgresql.org@donnacha.com>) |
Ответы |
Re: Design Strategy WAS: High-Profile Advocacy Opportunity:VbulletinForum
|
Список | pgsql-advocacy |
Oops! josh@agliodbs.com (Josh Berkus) was seen spray-painting on a wall: > Christopher, >> Well, SAP has pretty consistently tried to apply this strategy to >> their R/3 application, which is _not_ a "limited class of web >> applications." > > Aha. The key word there is "suitable". I've supported some > SAP-type applications, and they are messes of spaghetti code that > underperform their hardware by a factor of 10. As well as having > chronic data integrity problems that pretty much require an on-staff > application expert just to keep the thing running. There's a few of us around that have been "certified," once upon a time, and I doubt many would argue that R/3 is based on an ideal design. But the fact is that F500 companies decided to go with it. By the way, the way that they avoid "chronic data integrity problems" is by actively deprecating direct access to the data. Automated data input is handled via something akin to programming CGI; the CGI-like scheme runs data through the same screen-oriented logic used to validate data entered interactively. Efficiency is pretty horrible, but there are some elegant aspects to it; if automatically-entered data is _nearly_ right, the borken transactions can be kept on record, and a user can walk them through online, perhaps to fix some minor problems. There are things they do that _are_ worth emulating... > So I find SAP an excellent example of how *not* to write an > application, unless your goal is to maximize your support revenue. It is essentially what you get if you write a way-sophisticated ERP system with lowest-common-denominator functionality that amounts to about what MySQL offers (modulo "transaction" support). Yes, it requires a huge phalanx of developers and administrators. Yes, it's highly vulnerable to data corruption unless you apply pretty draconian system management policies. And remarkably enough, contrary to some vendors' marketing spiels, performance sucks remarkably badly. The point still remains that it _is_ there, quite dominant in the ERP market... -- select 'cbbrowne' || '@' || 'cbbrowne.com'; http://www3.sympatico.ca/cbbrowne/oses.html Rules of the Evil Overlord #222. "I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!" <http://www.eviloverlord.com/>
В списке pgsql-advocacy по дате отправления: