Re: Cost of ownership: MV vs. SQL Server


Glen wrote:

> On Mon, 12 Sep 2005 23:08:15 +1000, Luke Webber <luke@xxxxxxxxxxxxx>
> wrote:
>
> >Tony Gravagno wrote:
> >> Glen is right, too far OT.
> >
> >Too bad for Glen, I say. It's not like we're drowning in cdp posts here. <g>
> >
>
> Yeah, but people skimming the subject threads will never see the fact
> that we're arguing the realistic points of application development and
> deployment instead of the non-realistic points of which DB is better.
> I know that people are seeing the thread subject and saying "geez..
> not another stupid SQL versus MV thread".
>
> Glen

At the risk of losing you on the first sentence Glen, I don't think
it's stupid to discuss the differences - I actually think it's
important. I'd put it this way:

The vast majority of the application development and deployment that is
being / has been done with Pick/MV (PickBasic code etc.) is imbedded
within the Pick/MV DBMS, whereas it is external to SQL Server. SQL
Server is a database server - Pick/MV is a database/application server.
If you want to go down the M$ track then you're encouraged to treat
your DBMS in the way M$ treats its DBMS - regardless of essential
differences.

I'd suggest that not many businesses would select a brand new, empty,
Pick/MV DBMS over SQL Server for new application development using
predominantly M$ tools - which will always favour M$'s own DBMS
products - and yet many have chosen to re-engineer their existing
Pick/MV applications using M$'s tools (VB in particular). If that's the
way they choose to go then OK, although I question the wisdom of that
strategy.

It makes much more sense, to me, to go with a brand new, empty, Pick/MV
DBMS if you're developing applications with a browser UI, however,
because that allows the application server aspect of the Pick/MV DBMS
to shine through - and you're not locked in to M$ at either client or
server. So it seems sensible to me that if a company is looking to
re-engineer existing Pick/MV applications they should also choose to go
for a browser UI.

Cheers
Mike.

.

Relevant Pages

  • Re: ConnectionString using DSN not working
    ... applications that can work regardless of which backend database engine is ... This assumes that each DBMS is the same--supports the same SQL ... take advantage of the specific features you pay for when you buy SQL Server ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Fast_commit, sole_server, shared_cache combinations
    ... then its pages will stay in DBMS ... The cache seems to be fine and hits % is reasonable. ... >Perhaps simply starting another DBMS server without doing database ...
    (comp.databases.ingres)
  • Re: File-System or DBMS? (non-flammable clothing optional)
    ... You are simply distinguishing Pick/MV DBMSs from the rest on the ... DBMS's contain all data formatting and logical testing within the Database ... There is no generally-accepted definition of what a true DBMS is, ... I understand it) to a SQL DBMS, but it is precisely because it is Pick ...
    (comp.databases.pick)
  • Re: File-System or DBMS? (non-flammable clothing optional)
    ... You are simply distinguishing Pick/MV DBMSs from the rest on the ... DBMS's contain all data formatting and logical testing within the Database ... You get DataBasic as part of a Pick/MV DBMS. ... You don't HAVE to use intergrity constraints in an SQL RDBMS either - ...
    (comp.databases.pick)
  • Re: choices regarding where to place code - in the database or middletier
    ... > scalability " ... > DBMS, because it uses only the functionality offered by the DBMS that is ... Not once has Oracle ... Oracle Shared Server / MTS. ...
    (comp.lang.java.databases)