Re: What so special about PostgreSQL and other RDBMS?

Erland Sommarskog <[e-mail]> wrote in message news:<Xns94E6F1BC7C070Yazorman@127.0.0.1>...
> Dmytri Kleiner ([e-mail]) writes:

> > Good thing that you only mislead a few customers into overpaying for
> > crap. Your company is just a bankruptcy waiting for a competent
> > competitor to make it happen.

> Our customers seems to be quite satisfied with our system.
> 
> And - in difference to you - they actually know the system in question,
> so I think they are somewhat better apt to tell whether it is crap or
> not.

The Application that you wrote I have no reason to doubt is of
sufficient quality to keep your customers satisfied.

Unfortunately you have created unneeded dependencies for them, the
worst of which is not MS SQL, since it is fairly easy to get at data
in MS SQL and archive it or export it in a usefull way, the worst is
that you have tied your customers to a terrible Operating System with
a terrible licence, even Oracle users are not so screwed since at the
very least they have a choice when it comes to OS.

> > What bunk, saying the competitor tried 'precicely what I teach' and
> > thus failed is an obvious attempt to fallaciously discredit my
> > argument with out actually addressing it. You're a ham fisted shill.
> 
> I think that I made it quite clear in my first post that your suggested
> strategy indeed may be very valid sometimes. But what I've been pointing
> out is that this far from always the case. 

I would say you made it quite clear that your basic message was that
it would be folly to do what I was suggesting, and that was your whole
purpose in posting, as I said, I can tell this by the obvious
rhetorical devices you used, claiming this unnamed third party did
'precicely what I teach' a wretchedly unlikely and unqualified
generalisation, followed by saying that this, implying that this
_alone_, lead to the failure of their project. This is obvious FUD.
The lack of any other content, or even specifics in your post is the
final damning evidence. As I said, you are a shill, and a ham fisted
one at that.
 
> Doing the sort of abstraction you suggested is *very* expensive,

It is not, as I've said, it can be as simple as writing a wrapper
function around your data access.

Not as expensive as having the system itself obsoleted by an obsoleted
dependency or the inabilty to get support for a dependency due to a
licencing dispute.

But for you, this is probably useless advice, since no doubt not only
have you chosen a SQL server with a bad licence, and an OS with a bad
licence, but no doubt you have also choses a development platform with
a bad licence, let me guess: Visual Basic?

As I said, enjoy your solvency while it lasts.

> and
> for small companies like ours or our competitor, this a huge enterprise
> to take on for systems with over 500 tables and over 3500 stored procedures.
> (That data is for our system; Obviously I don't have the data for our
> competitor's system, but I do know the business they were targeting.)

All the more reason to protect your investment and that of your
customer by not getting trapped into becoming dependant on a third
party for the continued operation of their own system.

But it's pretty clear that encouraging such pitiable dependencies is
exactly what you are here to do.