[DUG] Why InterBase

[Alan Rose]

Speaking of axes boy do you sound like your got one to grind.
Sounds to me like your just reading into everything said literately,
just for the sake of an argument.
Purists don't impress me. Sometimes performance is more important than
idealistic coding practices. 
Its your way or no way is that right.

> -----Original Message-----
> From: delphi-bounces at ns3.123.co.nz 
> [mailto:delphi-bounces at ns3.123.co.nz] On Behalf Of Neven MacEwan
> Sent: Thursday, 1 June 2006 2:27 p.m.
> To: NZ Borland Developers Group - Delphi List
> Subject: Re: [DUG] Why InterBase
> 
> Alan
> 
> Clearly you have not implemented MSSQL or MSDE, This sort of 
> logic had some cost/functionality basis but as MSDE is free 
> its pretty much non sequitur, Why you would bother to use 
> three tools based on some archaic mantra is beyond me, I 
> would never bother with Access.
> 
> You raise a couple of other issues
> 
>  > As for single user well take your pick. Don't go over the 
> top. MS  >Access etc are fine.
> 
> Do you also use a blunt axe if the wood is soft?
> 
>  > I reckon If you design your
>  > tables right you should be able to avoid the need for 
> complex joins  > anyway.
> 
> Normalisation is bad? get real
> 
>  > A good design will avoid db corruption when power lost etc.
> 
> How?
> 
> Cheers
> 
> Neven
> 
> 
> > I would say MSQL and Oracle are ideal for organisations who 
> deal with 
> > very large volumes, run mutli-processes constantly and have 
> an IT team 
> > to support it (typically a DBA present). They make use of the many 
> > features that come with these heavy weights and would use complex 
> > joins etc a lot. E.g. Telecom and typically large organisations in 
> > heavy populated countries like US.
> 
> 
> > 
> > IB or FB is a great choice for the next layer. i.e. small to big 
> > business. Ideal for most businesses typically found in New Zealand.
> > Ideal for those without a DBA or simply just don't need the extra 
> > functionality as found in Oracle or MSSQL. I reckon If you 
> design your 
> > tables right you should be able to avoid the need for complex joins 
> > anyway. This is where experience helps with forward planning. J
> > 
> > As for single user well take your pick. Don't go over the top. MS 
> > Access etc are fine.
> > With client side caching you could even handle 1 to 3 users. If you 
> > know your stuff.
> > 
> > As for reliability a lot of it comes down to the 
> programmer. Keep it 
> > simple. Know your database limitations, avoid data-aware 
> controls (i.e.
> > use client side caching, download only data that you need for 
> > performance). A good design will avoid db corruption when 
> power lost 
> > etc. Make sure your clients understand the importance of 
> backups and 
> > you should be able to sleep comfortably at night. I know I do.
> > 
> > _______________________________________________
> > Delphi mailing list
> > Delphi at ns3.123.co.nz
> > http://ns3.123.co.nz/mailman/listinfo/delphi
> > 
> > 
> 
> --
> Neven MacEwan (B.E. E&E)
> Ph. 09 620 1356 Mob. 027 4749 062
> 
> New Address Details
> ===================
> MWK Computer Systems
> 1 Taumata Rd
> Sandringham
> Auckland
> 
> Ph 620 1356
> Fx 620 1336
>