Subject | Re: [firebird-support] Re: RE: How would Firebird prevent users thrasing database |
---|---|
Author | Rafael Szuminski |
Post date | 2004-04-06T22:12:10Z |
> Not only that (which I agree with), but I'll tell you how it worksAmen to that. In the past two years we have signed up multiple new clients just
> in real life. In real life, your single biggest client comes to you and
> says "we want to be able to access your files in order to do x, y or z".
> (In our case "because our chartered accountants have written a web based
> MIS system that will draw data from your files".) So now you have a choice.
> Either you tell your biggest client to go to hell (and make sure that it's
> a multi - billion $ international corporate while you're doing it, like
> ours is), or you have to write a whole bunch of work arounds and extra code
> to allow them to do that.
>
> Or else you get a huge "opportunity" - a possible sale - which falls
> through because their IT guys are as sharp as you are, and think that this
> idea of you holding them to ransom isn't actually a very good idea.
>
> Or else the engineering manager and the support manager tell the board that
> it is extremely difficult for any of the 50 or so field engineers to
> support the program in the field, because of all the extra security you
> have put in place to make sure that no - one except you understands what
> you've done.
>
> Or else your product target market becomes more and more limited because
> your application can't speak the standard Structured Query Language, and
> nobody exept you can fix it when it's broken.
>
> Where did you learn your programming style? Microsoft? :-)
>
> In my experience, the kind of security spoken about is far more trouble
> than it is worth, and limits your options severely. Hell, IMHO, even
> password / user level security is only worth all the effort in very
> specific cases - and then NEVER to "protect" my own code - like in
> Financial or Asset management systems, where you want to see who has done what.
>
> Regards
>
> Tim
because unlike our competition we give them full access to the db (including
support and training). Of course we have them sign a paper that we are not
responsible for data damadges... :-)