Re: Cost of ownership: MV vs. SQL Server

Tony Gravagno wrote:
> Kevin wrote:
> >> Why would one use ODBC? It caters to the lowest common denominator.
> "dawn" wrote:
> >If you are using SQL against MV, for example, ODBC would be your best
> >choice for most products. I haven't seen a native U2 driver for
> >Crystal Reports, for example.
>
> That's true but since CR has a .NET interface you can get your data
> from anywhere that supports .NET without a native driver.

That is impressive. I try to keep current in the "everything but MS &
..NET" category since I don't know how to keep up with that too. I'll
rely on you and others to pass along gems like that. Unfortunately,
shortly thereafter I'll forget the info because I have no folder system
in my brain to host it -- unless and until I decide at some point to
add .NET to my repertoire.

> That's one
> of the main features of ADO.NET, the source-independent nature of the
> dataset, and a lot of products are opening up to this technology.
>
> Kevin wrote:
> >> I use the native drivers/API to take full advantage of whatever
> >> db I'm using.
>
> That can be a double-edged sword. Using the Oracle OCI, for example,
> might get you more robust connectivity to the data but the same
> connectivity would need to be completely re-written for another DB.

You can be OS-independent, language independent, database independent,
app server independent, etc, but you cannot be all of those at once.
Even if you could, there would be no cost-benefit analysis that would
suggest you should.

So, you need to decide to partner in one or more of these areas and
help your partner be successful to protect your investment. If you
decide to partner with Oracle and skip the db-independent approaches,
then using native access would make sense. If you decide to be more
db-independent, then you could still write your own wrapper that uses
each db's native access, but it likely makes sense to use an existing
library as there are a number of approaches for SQL-DBMS-independence.

> Again there area myriad of DB-specific DataProvider/DataAdapters for
> .NET, so your code is only minimally platform-dependent when using
> .NET technology. Coding with the D3 Class Library gets you D3-only.
> Coding with UniObjects, and UO.NET still gets you U2-only.
>
> For these reasons and many others, I'm increasingly in favor of using
> .NET in general, and for MV connectivity using mv.NET in particular.

If you opt for MS as a significsnt partner, then you end up with a
powerful partner who you don't need to nurse along at this point, but
you do have a greater risk of having all of your eggs in one basket
than with some other approaches. I am looking to see if that problem
becomes lessened in the future.

> Coming back to Crystal Reports, this means you can setup an MV
> datasource for your CR reports using Pick Access/Recall or even using
> BASIC to generate a select list and return data, not just SQL via
> ODBC.

I would love to see that. It would seem there are assumptions even in
the reporting tool UI that anticipate "normalized" data, although
hopefully this is changing with xml data sources coming into play. I
haven't seen xml-based reporting tools yet, however, other than raw
XQuery. I have a tool loaded, but just haven't had the time & priority
on it.

>
> >> > Still, MV is
> >> > preferable for situations where the applications require frequent
> >> > change, without having to redo multitudes of GUI forms and distribute
> >> > upgraded client binaries to everyone.
> >>
> >> Not sure if you're saying MV is preferable because you don't have to
> >> deal with GUI, or it's preferable when you don't have to deal with GUI.
> >> I suspect you're saying the latter. Regardless of DB, GUI does add an
> >> entire layer of complexity in development/deployment.
> >
> >I've recently decided to dump all but web-based development for the
> >future, given that you can create reasonbly rich UI's in a browser now.
> > This eliminates any need for client-side deployment.
>
> In response to all of the above comments, all three of you are missing
> the alternative "Zero Touch Deployment" available with .NET.

In case it isn't clear, I am missing everything related to .NET.

[I did look for what would be used for a query language with WinFS and
I have a vague idea of some MS terms -- Yukon as the code name for SQL
Server 2005, Longhorn for the next version of Windows (which has
another name I'm forgetting), and Longhorn will have WinFS as a
component, which happens to be the engine behind Yukon/SQL Server (if I
have this right). If Excel, Word, etc are going to use the SQL Server
engine for documents, then the front-end tools to this engine will need
to have some new tricks, including not relying solely on SQL as the
query language, I suspect. I see them talk about a "natural language"
interface (and if you were around in the 70's & 80's that sounds like a
blast from the past) but I don't know what language it will translate
to, if any, before executing against the db. I'm very curious, so if
anyone has this figured out, please advise. Is particular, where is
XQuery in this mix?]

> The
> application is initially deployed through a browser. After that, when
> the thick-client app is run it checks for updates from the remote
> server.

That sounds something like Java Web Start, perhaps?

> Updates are made automatically and the end-user always has
> the latest version. There are no deployment issues.

Is this the case for Macs? Linux desktops? Phones? PDAs? Other
non-MS client environments?

> Regarding the relation of MV to GUI and related deployment, these
> concepts should kept separate. Even the mention of such things is
> indicative of this market as being behind the times.

I'll take that .NET learnin' from you, but if you are about to lecture
me on model-view-controller ... ;-)

> I don't think
> relational people ever discuss how tough it is to deploy a GUI app in
> relation to the data, except when considering things like local/remote
> or disconnected data sources. Properly organized code wraps calls to
> the data source in business objects which are then used by the UI,
> whether thick or thin. Deployment isn't a database issue it's a
> design issue.

Relational folks assume that the data is properly modeled in the
database and if anyone wants to use it in a user interface, they will
need to use completely different modeling techniques and will need to
do the mappings between relational and UI models.

Design includes data models for UI and DB. How one models the "real
world" is influenced by the data model approach of their target
environment(s) -- in other words, I think MV folks and relational folks
produce different logical models of their problem domain. We could map
big leaps forward if we use tools that have no intermediate mappings of
anything to 1NF relations. Look at the huge Object-relational mapping
industry that is springing up. We could bypass all that with good
tools or standards. [I don't think I wrote that well, but don't know
how to fix it, so apologies if it was not clear.]

> If you're going to design something improperly you're
> going to have deployment issues no matter what database you use.
>
> About the web vs thick client decision, I'm sort of inclined to agree
> but there are advantages on both sides. These days there are
> components for developing attractive browser-based UI's that can be
> indistinguishable from a thick client - I've seen complex forms, for
> example, that I couldn't tell that they were web forms except for the
> IE container around them.

I'm using gmail from google and it is the best mail client I've ever
used from many perspectives.

> IE isn't required for this sort of UI but I
> think it's preferred.

It is OK as one browser, but not prefered by Mac clients, for example.
On Win XP I use FireFox more than IE. IE isn't available for all
platforms, but one web browser or another is.

> Some people will still scoff at the idea of
> using IE at all. In this case, this or any other browser is less of a
> web surfing tool and more of an application container - it's not a UI
> but a deployment mechanism. Used in that context even the most
> anti-IE people in the crowd don't have much to room to complain.

I don't quite follow this point. I see the browser as a client
run-time container and the web server as the deployment mechanism for a
particular app.

>
> > Although the MV
> >GUI then looks like any SQL GUI at first glance, it still gains from
> >the data modeling done for MV (so that users really do have choices of
> >multiple values when they want them, for example). That sets MV
> >solutions up to be similar for an end-user to XML-backed solutions.
>
> This confirms what I just said above. We can make the best of our MV
> apps and data structures, just don't confuse that with UI,
> connectivity, or deployment.

I should have made a distinction between the View (data model for the
UI) and the specific UI.

>
> >However, issues for the MV community include that there are no standard
> >libraries (in java, php, etc) for connectivity. It is a shame that
> >with so much standardization in the base product, the MV vendors could
> >not provide any standardization for client-server connectivity.
> >cheers! --dawn
>
> [ad alert]
> Dawn, I think we (Pickies) have a new solution. I highly recommend
> investigation of mv.NET and I'll be happy to help with that process.

At this point I have been working with open source and other similarly
low-cost solutions. I have knowledge of Java, JavaScript, XHTML, CSS,
PHP, XML and other TLAs but I'm not yet satisfied, while it sounds like
you are. What is going for me on this side of the house is that I
think google has some of the best minds in the industry and most
satisfying applications. In the google vs Microsoft wars now and to
come, I'm happy at this point to align with google's application
development strategies unless or until I decide it just isn't going to
work for me. But if someday I decide that .NET is a better direction or
needs to be part of a solution, you know you'll hear from me :-)

> This toolkit is cross-platform for D3, jBASE, mvBASE, Power95,
> Reality, Universe, Unidata, and Univision. They may also add support
> for mvEnterprise and Revelation OpenInsight. I think they support any
> OS platform that these DBMS products run on, and they pretty much
> support any available release of these products as well. That's about
> as "standard" as any connectivity tool is going to get in our market.
> mv.NET comes from BlueFinity International which is a "sister company"
> to jBASE. The corporate backing for the product is high and support
> is excellent and personal. I have nothing but praise for the product
> and the people who make it available. I know many of our colleagues
> are now adopting mv.NET, perhaps some of them will make their own
> statements here.

Maybe I should work with them to imitate this approach on the non-.NET
side of the house? If I understood what .NET provides, then perhaps I
would understand what it would take to do something similar for Java,
PHP, and other environments.

> In what way is it a standard MV product? In short:
> - A single library allows manipulation of accounts, files, and all
> dynamic array structures, plus execution of BASIC code on any server.
> That's one library for all MV platforms.
> - The library includes many utility functions and function overloads
> that make it more familiar and friendly for MV developers.
> - Grids, listboxes, and other components are easily bound to MV data.
> - Indexes and transactions are supported, based on whatever
> functionality is available from the DBMS.

Impressive. Unfortunately, if it requires .NET to operate, then it is
anything but "standard" in my world, but I should take a look sometime
anyway.

> For .NET developers who aren't familiar with MV at all, the ADO.NET
> integration also makes MV data available using syntax that's familiar
> to them, and using any language they want, including most of those
> listed here: http://www.dotnetpowered.com/languages.aspx
> [/ad]
>
> There are no universal language access solutions across DBMS
> platforms. SQL syntax and other nuances vary in many annoying ways
> for relational DB platforms, much like MV products. So
> "standardization" shouldn't be put on the table as something that is
> available in the SQL world but not in ours

I have been intimate with ODBC against multiple DBMS's and you are
definitely right. In fact, MV languages are much more standard across
products than is SQL across RDBMS's, so it is the client/server (or
however you want to say it) standard that is lacking. If mv.NET could
be expanded to be useful outside of .NET ...

Cheers! --dawn

> - I know you didn't say it
> was, but the implication is sort of there. And as I've indicated
> above, I think UI and deployment concerns should be off the table as
> well.
>
>
> Inquiries about mv.NET are welcome.
> TG@ removethisNebula-RnD .com

.

Relevant Pages

  • Re: serializable isolation level behavior question
    ... When did the truncate command become part of the SQL standard? ... and some other client does a truncate ...
    (comp.databases.oracle.server)
  • Re: serializable isolation level behavior question
    ... When did the truncate command become part of the SQL standard? ... and some other client does a truncate ...
    (comp.databases.oracle.server)
  • Re: serializable isolation level behavior question
    ... When did the truncate command become part of the SQL standard? ... and some other client does a truncate ...
    (comp.databases.oracle.server)
  • Re: Dont understand what version of SQL to install
    ... I'm talking about developing and testing databases for my client and ... To my XP, I can add SQL Developer 2008 to develop (I guess I should say, ... So I can use SQL Developer 2008 to create a database in standard 2005, ... installed on Client OSs such as Windows Vista. ...
    (microsoft.public.sqlserver.setup)
  • Re: DataSet.GetChanges() in RowChanged(DataRowAction.Add)
    ... have you considered SQL Express and use ... > I realize now that I didn't describe well how the client application is ... > Framework installed on the client machine, but not any SQL Server). ... > 20 tables in different relations with eachother in the database, ...
    (microsoft.public.dotnet.framework.adonet)