Mike Stone wrote:
> Jack Killpatrick wrote:
> >The key point here is that I can use MySQL on NT with ColdFusion, with
> >probably just a few hours of work changing the SQL statements to
> jibe with
> >the MySQL ODBC driver. Also, by having my data in MySQL on NT, I
> am probably
> >only a short step away from being able to move it over to a Unix
> box - which
> >I will probably do, depending on my scaling needs and schedule, when a
> >native version of CF comes out for HPUX or Linux *or* when/if I decide to
> >port to PHP.
>
> sounds like a sensible way to go about it, IMHO. it certainly shows
> willing on your part, which gives you some counter-thwocking power if the
> system types still feel like digging their heels in.
After meeting with our network consultants today and going over our needs
and talking about growth, they decided (much to my surprise) that we would
be fine if we start with putting the database on it's own machine (OS and DB
still to be determined) connected to NT web servers running Cold Fusion.
They figure that we'll be able to put approx 200 domains (all relatively low
traffic) on each NT machine and would be able to grow to at least 1000
domains (or 5+ NT servers) before having to reconsider our
hardware/software. By the time we get to 1000 domains, we will be well
beyond startup phase and will be able to consider alternate web server
machines. Chances are that *before* we get to that point there will be a
native Unix version of ColdFusion and we could easily convert the NT web
servers to Unix: install OS, setup server software, install CF, copy CF
templates to the new system and go.
We are still evaluating the database software. We're going to setup some
different configurations and stress test them in a few days. I'll let you
know the results when we figure them out. Chances are that we will be going
with Unix/MySQL/MySQL ODBC for the database server. That'll mean that the NT
machines will be running Cold Fusion, but connecting to the Unix based db
via the MySQL ODBC driver. If we go that route, we'll have the most
important stuff, the database, on a more fault tolerant system than NT, with
dual SCSI drives mirrored, which will make us all sleep better.
> eliminating inner joins can be a bit of a pain.. usually it involves more
> data handling or storing at the query end. the good news is that it's
> unlikely you'll need to redefine the tables themselves.
Tomorrow I'll be porting a chunk of SQL to something that MySQL can
understand...and then we'll be stress testing. Do you have any idea of what
the basic workarounds are for replacing INNER JOIN's? I've done some digging
and found other people asking the same question, but the answers haven't
given me a clear path, if there is one.
I figured that I wouldn't have to redefine any tables, but I'd also like to
avoid using extra queries to evoke a workaround. Word *was* that the last
release of MySQL was to support INNER JOINS, but it didn't happen. I think
the developers decided to add subselects instead. I read that they had to
make a decision between the two for this release...guess they decided
subselects were more important.
> just to make your life slightly more difficult, you might also want to
> check out postgresql.. i believe it comes as part of the default
> installation of Red Hat. it's compatible with PHP, and offers a fairly
> wide range of APIs and tools:
>
http://www.postgresql.org/
> granted, this isn't likely to be an immediate contender if you want to
stay
> on NT/CF long enough to get things rolling. it's primarily unix based,
> but has the advantage of being free. one more thing more to look at, at
> any rate.
Word is that it's slower than MySQL, probably because it has transaction
handling and row-level record locking. The guys at MySQL say they don't want
to put transaction handling in due to the performance hit (can't they find a
workaround?). Again, a point that I am debating: do I need transaction
handling or not? At this point, and in the foreseen future, no, but the key
word is "foreseen" ;-) I don't need row-level record locking.
> off the top of my head, i don't recall if postgresql supports inner joins
> or not.
I'm not sure, I browsed the non-searchable (which is kinda lame) postgres
docs and the only thing I could find is that the word INNER is a reserved
word.
> i know it supports some object-oriented features like
> inheritance, and that can be used in ways similar to a join. probably
not
> a range of technology you're interested in learning just right now, but
> it's worth considering for your long-term plans.
Maybe this Saturday....between 4:17 and 4:23 :-P
Thanks,
Jack
____________________________________________________________________
--------------------------------------------------------------------
Join The NEW Web Consultants Association FORUMS and CHAT:
Register Today at: http://just4u.com/forums/
Web Consultants Web Site : http://just4u.com/webconsultants
Give the Gift of Life This Year...
Just4U Stop Smoking Support forum - helping smokers for
over three years-tell a friend: http://just4u.com/forums/
To get 500 Banner Ads for FREE
go to http://www.linkbuddies.com/start.go?id=111261
---------------------------------------------------------------------
