[DUG] Why InterBase

[Neven MacEwan]

Alan

> 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.

I was simply expressing an opinion..as you were
I accept the 'horses for courses' argument when its valid

> Purists don't impress me. 

I won't ask you on a date then however if i was a purist I certainly 
wouldn't be an engineer - to many compromises

> Sometimes performance is more important than
> idealistic coding practices.

 From this you are saying that Access outperforms IB and MSSQL?

> Its your way or no way is that right.

Only in my right to express an opinion on this list

Neven


> 
>> -----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
>>
> 
> _______________________________________________
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: neven.vcf
Type: text/x-vcard
Size: 164 bytes
Desc: not available
Url : http://ns3.123.co.nz/pipermail/delphi/attachments/20060601/bf5a4cc1/neven.vcf