Re: LDBC driver
- From: Silvio Bierman <sbierman@xxxxxxxxxxxxxxxxxx>
- Date: Thu, 05 Jun 2008 09:40:49 +0200
Lew wrote:
Silvio Bierman wrote:Agreed. For that reason we advise large-scale users to stay away from MySQL and SQLServer. The generic database handling we have allows us to implement a database-clone action from one provider to the next and we have used that several times to "upscale" users from MySQL or SQLServer to PostgreSQL or Oracle.
We have had to migrate our own ASP platform from MySQL to PostgreSQL when usage levels began to increase.
I would never implement the workarounds you describe for SQLServer in any system if using a different database system is an option in any way. Since our software is a standard system we do not even offer large-scale performance on poorly-scaling database backends.
Interestingly, Silvio, your company's product is exactly the use case that would ostensibly benefit from something like the LDBC driver, if it didn't already have equivalent code in place.
OTOH, from your description it sounds like that level of abstraction was not at all difficult to achieve for you.
I didn't see anything in the LDBC site that would account for the sort of algorithmic adjustments highlighted by Thomas. I suspect that that type of thing will always require a programmer / analyst to pay attention case by case.
That's why they pay us the big bucks / dinero.
In a way that is true. However, putting a similar abstraction in place is a minor effort. That, and the fact that this can be more easily tailored to the needs of the application and the surroundings it will run in than an external tool which might even bring unknown surprises with it makes me prefer the self-written code in this case.
To be honest this is a decision we often make in retrospect as well.
We use a reverse proxy for load-balancing purposes on the ASP platform and started with Pound, then moved to yxorp but needed some facilities both could not provide and finally decided to code a reverse proxy servlet ourselves. This proved quite easy (took me about three hours).
It has every facility we need, performs much better and is pure Java (the other ones are written in C and did not run on Windows).
We used JFreeChart for generating graphs in the report-generation part of our software. Users kept beating us around for tiny details (and some major logic issues) they would like to see changed but where hardly or at all feasible with JFreeChart.
Finally (after over two years of hassle) I decided to make our own. Took quite some effort (about two weeks of development) but now we have something that generates better looking output and that we can control at the sub-pixel level.
I must say that we are almost solely working on the standard product we provide and support. That makes the development cycle a lot different from developing custom products from the bottom up each time. We do that as well (be it less and less) and in those cases we do make different decisions.
I guess it all depends...
Silvio
.
- References:
- LDBC driver
- From: blueparty
- Re: LDBC driver
- From: Lew
- Re: LDBC driver
- From: Thomas Kellerer
- Re: LDBC driver
- From: Silvio Bierman
- Re: LDBC driver
- From: Lew
- LDBC driver
- Prev by Date: Re: LDBC driver
- Next by Date: Hibernate question/Classes that contains a Collection
- Previous by thread: Re: LDBC driver
- Next by thread: Re: LDBC driver
- Index(es):
Relevant Pages
|