Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
JVP, flexibility of databases
Message
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00851534
Message ID:
00852802
Vues:
42
>
There is still a whole class of apps out there where security is not an issue and where dbf is as scalable as the client needs, and where the client does not have a DBA on staff to maintain the database. MSDE still has a 5 connection limit right? So the 6th simultaneous user forces the jump to SQL. DBF doesn't have that constraint, it can handle the medium size connection load better than MDB.
>

I don't buy into the notion that security is not an issue - rather - It is often an ignored issue.

>>SQL Server is the hands-down winner as far as flexibility, scaleability, and robust-ness is concerned.
>


>Flexibility - exactly how do you define/measure this? In some respects I'd say SQL is less flexible. But I'd like to see your definition of flexible first.
>

It is more flexible in that security is integrated and there is also an integrated tx log. Further, the engine scales from everything including a pda to a larger server. Also, sql server databases are easier to administer remotely. In terms of language, there is both sql and a procedural language -which together makes up t-sql. SQL Server's implementation of sql is far more flexible than what you will find in Fox.

Regarding MSDE - you bring up a good point. But - you can get into the desktop version of SQL Server for about 800 bucks or so. In the grand scheme of things - that is not a lot of money. At some point in the near future, I would not be surprised to see a more robust version of MSDE integrated directly into the OS....

I am not saying that DBF's are not flexible. All I am saying is that trying to prop up DBF's at the expense of SQL Server is a folly argument. There are too many compelling reasons to choose SQL Server over Fox. And yes - I agree that for small (very small) jobs - dbf's can and will be successful. But - if you hitch your horse to the dbf-post - your options and opportunities are limited.

Dave - if dbf's were that compelling - not only would more companies use them - the would be considered a credible storage medium for mission critical data.


>
I hope by attack here you mean solve a given problem, not the more negative connotation.
>

Yes - that is what I meant - to solve a problem...


>
There exists three classes of data-based apps in the world: 1) those where DBF is appropriate and 2) those where SQL is appropriate and 3) a middle ground where either DBF or SQL would be appropriate. #2 and 3 are what interest me the most. In a lot of the data centric work that I end up doing the best method has been to pull the data down from SQL into DBFs, mess with it and push the result back up to SQL.
>

I think your categories are wrong. For one thing - you ignore MDB's. I don't know why you and others dismiss Access out of hand. I would also contend that where DBF's could satisfy a client's requirements - MSDE would be a good fit as well. Way too much is made over the supposed connection limit. When you get down to it - you only need a connection when you update and query data - that is it.

FYI - MSDE can have more than 5 connections. The governor kicks in with processes. I believe Kevin McNeish posted something about simulating 250 simultaneous users on MSDE. Try creating 10 simultaneous connections on MSDE via ADO - you can do it....

>
And I think the most productive discussions will come from how combinations of VFP + .Net + DBF + SQL solve client problems.
>

If you say so... Tell you what..go to a prospective client who is considering .NET and try and sell dbf's... And, as time goes by, it is FAR from clear exactly how VFP will play in the ever evolving managed code sandbox.


>
How is it that a remote view is fundamentally any different than a SPT cursor or different than an ADO.Net view to the backend? They are all just a data layer.
>

For one thing - a remote view is a VFP-specific wrapper around SPT. And in its implementation - is quite incomplete. Indeed - it is a data layer - but it is a VFP-specific implementation.


>Please don't lump everyone into such confined buckets ok?

Why??? You dumped all the classes of applications in the world into 3 buckets? I just gave an opinion on which VFP developers I see as being more accepting of .NET today. It was not meant as a slam or an insult. Glenn Beck is absolutely right when he says that politcal correctness is a good concept gone bad...


>
Sweeping statements like these are what raise much of the ill feelings.
>

Unjustifably I might add.... If people get personally PO'd at stuff like this - they need to not be so sensitive.
>
Neither you or I know every VFP developer, nor every .Net developer nor every VB nor every Java developer. Anyone open minded enough to seriously look at this issue is capable of looking at two sets of code and evaluating which of them solves a problem in the best manner in their own opinion.
>

I agree that "open mindedness" is the key. It just so happens that trait is more prevelant in some than others. That said, I have run into enough developers to provide an informed opinion. If you disagree - then do that. But please - don't tell me how I should go about making my opinion when quite frankley - there is nothing whatsoever that could reasonably construed as offensive. In effect - what you are saying here is that my opinion is OK to the extent that it does not offend anybody. Sorry Dave - I don't accept that as a predicate to express an opinion.

< JVP >
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform