Re: Data Access...
- From: "Ty Salistean" <tsaliste@xxxxxxxxx>
- Date: Wed, 8 Jun 2005 17:06:25 -0500
> > > Well yes, but there are also plenty of apps which save data but don't
> > > need to use a database. Most word processors don't have databases in
> > > them, for example...
I assume people read things in the context of the subject. Since this post
originally had to deal with DATA ACCESS lets talk in terms of DATA ACCESS.
So if you do not access data, then please do not respond.
It would be nice if we could get an ANSI standard SQL compliant way to
manipulate data, for those people that need to manipulate data in
datatables/datasets.
> > > How is a SQL engine a compromise? It's a *lot* of work, and in many
> > > cases still wouldn't give as much ease and flexibility (and compile-
> > > time type safety) as a callback-based filter.
> >
> > I am sure data technologies such as RDO, DAO, and ADO were not easy to
> > accomplish. Why did they suck? Data manipulation, navigation, etc...
>
> I don't see your point. I was offering a much more straightforward
> solution to the problem - one which would give a similar amount of
> power, making things easier in some cases and harder in others. It
> would not only be easier to implement, but much cheaper in terms of
> space, so it could be available on space-limited devices.
My point was that RDO, DAO, and ADO took *alot* of resources and they still
suck. What was the main problem with them? Data manipulation, navigation,
etc... I think it is time to address the real issues...
> SQL wouldn't accommodate everyone to start with. There are many things
> which are hard to express in SQL but easy to express programmatically.
> Consider a data table which doesn't just store strings, numbers etc,
> but rich objects - how would you access those in ANSI SQL?
The same way SQL Server and every other SQL compliant database handles it.
Using the ANSI standard is a better soution, to me. I am sick of buying and
learning 3rd party tools. I want enterprise tools out of the box. I can
choose to use those tools or not.
It would take more time to get a SQL engine plugged into .NET than your
solution. But then things, like adding a row(s) to a datatable would not be
so cryptic or updating a row(s) would be auto-magical. How cool would that
be?
I am curious if anyone else has any input. Please post.
"Jon Skeet [C# MVP]" <skeet@xxxxxxxxx> wrote in message
news:MPG.1d116419b27c8dc898c29c@xxxxxxxxxxxxxxxxxxxxxxx
> Ty Salistean <tsaliste@xxxxxxxxx> wrote:
> > I will say that by using an ANSI standard for re-filtering data is still
a
> > better option. Someone coming to .NET from and SQL compliant language
would
> > be able to understand the syntax alot better.
>
> And someone who comes from a non-SQL background will find it harder to
> use. There are swings and roundabouts, but you've got to admit that it
> would take a *lot* more effort to write a full SQL engine than to
> include callbacks.
>
> Bearing in mind that MS doesn't have unlimited resources, I suspect
> that there are if callbacks were in place to cope with 99% of filters,
> those resources would be better spent elsewhere.
>
> Heck, with sufficiently powerful callbacks in place *you* could write
> your own SQL engine if it's that important to you. Or another 3rd party
> could, and charge for it.
>
> > What other manipulation tool would accomodate everyone?
>
> SQL wouldn't accommodate everyone to start with. There are many things
> which are hard to express in SQL but easy to express programmatically.
> Consider a data table which doesn't just store strings, numbers etc,
> but rich objects - how would you access those in ANSI SQL?
>
> > > How is a SQL engine a compromise? It's a *lot* of work, and in many
> > > cases still wouldn't give as much ease and flexibility (and compile-
> > > time type safety) as a callback-based filter.
> >
> > I am sure data technologies such as RDO, DAO, and ADO were not easy to
> > accomplish. Why did they suck? Data manipulation, navigation, etc...
>
> I don't see your point. I was offering a much more straightforward
> solution to the problem - one which would give a similar amount of
> power, making things easier in some cases and harder in others. It
> would not only be easier to implement, but much cheaper in terms of
> space, so it could be available on space-limited devices.
>
> > > Well yes, but there are also plenty of apps which save data but don't
> > > need to use a database. Most word processors don't have databases in
> > > them, for example...
> >
> > We can discuss this all day. Then do NOT include the
System.Data.SQL.dll
> > (or whatever) with your app.
>
> Sure. I'm just disputing your implication that it was shocking that
> people might be using .NET without knowing SQL. You seemed to be under
> the impression that all apps *should* be using databases. That's just
> not the case.
>
> > At least we can agree that if you are working with data, it would be
nice to
> > have some other way to process that data easily. To be completely
honest, I
> > do not care how they do it...simply realize the need is there...
>
> Yup.
>
> --
> Jon Skeet - <skeet@xxxxxxxxx>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too
.
- Follow-Ups:
- Re: Data Access...
- From: Jon Skeet [C# MVP]
- Re: Data Access...
- References:
- Data Access...
- From: Ty Salistean
- Re: Data Access...
- From: Jon Skeet [C# MVP]
- Re: Data Access...
- From: Ty Salistean
- Re: Data Access...
- From: Jon Skeet [C# MVP]
- Re: Data Access...
- From: Ty Salistean
- Re: Data Access...
- From: Jon Skeet [C# MVP]
- Data Access...
- Prev by Date: Re: .NET Memory Problems
- Next by Date: Re: Data Access...
- Previous by thread: Re: Data Access...
- Next by thread: Re: Data Access...
- Index(es):
Relevant Pages
|