Lincoln Manning wrote:
> I am a part of the speed team at a fast growing internet startup. Our team
> is basically focused on speeding up user access to our system. We are able
> to handle our current load, but we would like to develop a speed growth
> plan. My specific questions are..
>
> 1. We have hundreds of car dealerships across the country that use our
> system based around a few large databases. What would be the benefit of
> creating a database for each dealership? Basically splitting everything
> into separate databases. Is this a management headache waiting to happen or
> would the smaller databases and speed gains be worth it?
>
Depends on the structure of your database. If, for instance, each
dealership is only maintaining contact information such as name and
address then you are probably dealing with only one row on a table
and breaking it up would seem not worth it.
If each dealership has gigs of data, then it may be something worthwhile.
Make sure that you are in a good database (SQL Server at the very least).
Avoid Access.
> 2. I know of a few large CF based companies that use large table views
> instead of joins for frequently requested information to get information to
> customers quickly. Has anyone tried this and what are the implications? Is
> there any software to automate this strategy?
>
err.. I'm not sure what you mean.
You mean instead of storing information in a theoretically correct manner,
with multiple tables, you want to bring it down to one table? I wouldn't
recommend that. Although, you may investigate a stored procedure type
of functionality, so that the database has already performed the join and you don't
have to do do it via ODBC.
> 3. Finally, I have been using SQL Profiler to track locking queries, and a
> few tables and few queries seem to be the most common. Are there any
> straight forward remedies. I have been using the (No Lock) option when I
> can. Are there other ways to minimize this?
>
Implement common queries as stored procedures, and/or cache them
if possible.
Warning, In the next statement I have no idea what I'm saying:
You'll probably want to use indexes on the most commonly used
tables.
Okay, I'm done with the ignorant stuff.
>
> By the way, we are using SQLServer 7.
>
:doh: I wish you said that first.
--
Jeff Houser | mailto:[EMAIL PROTECTED]
AIM: Reboog711 | ICQ: 5246969 | Phone: 860-229-2781
--
Instant ColdFusion 4.5 | ISBN: 0-07-213238-8
Due out 3rd Quarter 2001
--
DotComIt, LLC
database driven web data using ColdFusion, Lotus Notes/Domino
--
Half of the Alternative Folk Duo called Far Cry Fly
http://www.farcryfly.com | http://www.mp3.com/FarCryFly
--
Promise me no dead end streets, and I'll guarantee we'll have a road
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
------------------------------------------------------------------------------
To unsubscribe, send a message to [EMAIL PROTECTED] with
'unsubscribe' in the body or visit the list page at www.houseoffusion.com
