Re: LDBC driver
- From: Silvio Bierman <sbierman@xxxxxxxxxxxxxxxxxx>
- Date: Wed, 04 Jun 2008 12:53:44 +0200
Thomas Kellerer wrote:
Silvio Bierman, 04.06.2008 11:07: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.
Completely agreed!
Although I have the impression that a SQL Server user wouldn't call the concept of using temp tables a workaround but rather a design principle ;)
But then I was lucky to not have to use SQL Server a lot, so I might be mistaken with that assumption.
Thomas
I have used a lot of SQLServer in the past. We ran MySQL on the ASP environment (Linux boxes) and SQLServer on our development machines (laptops running XP).
Some of our larger customers insisted on running the system on their own Windows servers using SQLServer as well and we let them. As the databases and user bases grew they suffered steadily degrading performance for larger data imports and extractions.
In the meantime we had switched both our ASP environment and our development machines to PostgreSQL. On the same database content stuff that would take 30 minutes on their SQLServer setups (due to lock contention) would run in 30-45 seconds on my not-so-up-to-date laptop. That brought them around quite quickly. PG did the same job in about 15s on their Windows servers.
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: Thomas Kellerer
- LDBC driver
- Prev by Date: [red]Search for jobs in IT, marketing, software, finance.[/red]
- Next by Date: Re: LDBC driver
- Previous by thread: Re: LDBC driver
- Next by thread: Re: LDBC driver
- Index(es):
Relevant Pages
|