Database migration

Daryl Tester Daryl.Tester at iocane.com.au
Tue Dec 3 21:33:20 CST 2002


Andrew Reid wrote:

> OK. Dare I even suggest (seeing as we are, for all intents and
> purposes, a Microsoft shop, at the moment) that SQL Server is even
> worth thinking about?

Quite possibly, just for the effect of watching DSL gnash his teeth.
But seriously, there are lots of tradeoffs to be weighed up, and
SQL Server is quite probably worth considering.  Oracle, properly
tuned, is a real high performance database (it gives you complete
control over where you lay out certain tablespaces, so say you
have an index that's getting hit heavily, you can move it to a
separate file system / I/O channel), but that comes at a high
performance cost - it ain't cheap.  SQL Server is built on Sybase,
IIRC (either that or Ingres; I get the two confused), so it's an OK
database with GUI-fied front end, which probably means MCSE-like
DBA's will be a dime a dozen.  I don't know what it would be like
to recover/administer.

> ... not that I'm particularly keen to use it (the number of security
> advisories directly relating to SQL Server in the last few weeks is
> quite frightening), but it'll have to be a consideration.

I'd never point anything like a database server directly out onto
the 'net.  They're just too complicated to secure properly, both
from an administrative and in a secure-application sense.  If you
need direct access to the database (e.g., SQL), then a VPN would
be the way to go, otherwise access the data through a front end
application server.

> Still thinking about that. Perhaps, as was suggested to me by Dan
> Shearer, the backend can produce data in XML format to be rendered by
> whatever application we so choose, whether it be a Windows-native
> client, a web-based client, or something made out of toothpicks and
> creamcheese.

Bear in mind that, except for large result sets, XML may increase
the amount of padding around your data, unless you employ some sort
of datalink compression.

I find XML useful for foreign interfaces, and am more than content to
use [OJ]DBC (or the equivalent interface drivers) for an integrated
application interface.

> There's a fair bit of thinking to be done in that department, as the
> interface that we currently use makes fairly heavy use of some of the
> slightly interesting controls that come standard out-of-the-box under
> Windows and associated APIs; these would have to be rewritten in HTML
> or something if a web-based interface was to be produced.

And that, I personally feel, is the downfall of most HTML-based apps.
(Generalising a bit here) They look like web based applications, they
run slowly over dialup links (and often require multiple trips to the
server, especially if validation can't be performed locally using
Javascript), they're usually keyed to specific versions of browser.
But that's definitely just my opinion, and can be treated as such ...


-- 
Regards,
  Daryl Tester,  Software Wrangler and Bit Herder, IOCANE Pty. Ltd.

"Hey ho Mr. Krinkle, have you heard the brand new sound?
 It's a cross between Jimi Hendrix, Bocephus, Cher and James Brown.
 It's called Heavy Hometown New Wave, cold-filtered, low-calorie dry." - Primus

-- 
LinuxSA WWW: http://www.linuxsa.org.au/ IRC: #linuxsa on irc.openprojects.net
To unsubscribe from the LinuxSA list:
  mail linuxsa-request at linuxsa.org.au with "unsubscribe" as the subject



More information about the linuxsa mailing list