which database would you choose? 2

[StanKorn]

I am searching for a solution for our trucking company. We have approximately 100 employees currently and 80 are drivers. We currently are operating on a VFP platform that is poor in performance and is a bear to use for the dispatch and clerical desks. I have been researching various options over the past two weeks and have several possibilities.
I have received info on Java based system (McCleod) and two MS SQL based systems (TMW and Abecas) as well as a an MS Access option and several VFP products. I have also reviewed an AS-400 solution but it is priced out of reach for us.
Can anyone give me some feedback on the various solutions mentioned above (I am primarily interested in the MS SQL and the Java platforms). I am from an Oracle environment in a past life and while that software has certain advantages I would like to stay in the "off the shelf" variety of software specifically designed for our industry.
Thanks to all,
stan



Remember - only dead fish go with the flow.

 

[Terpsfan]

Of the different alternatives that have been put in front of you so far, I think the SQL Server route would be best. Oracle is a more scalable database, but it is a heck of a lot more expensive and is more for huge database projects. Access or Fox Pro should be ruled out. If you are willing to go the open source route, then look into PostGreSQL. The database has many of the capabilities of SQL Server and is more geared towards a Java application. One important consideration that many developers lose sight of is to design for the future...as in how many users are going to be using this database 5 - 10 years from now...how much data will I be dealing with 5 - 10 years from now. I know it's hard to think that far ahead but it sure helps in the long run because you don't have to go through the pain and suffering of redeveloping an application and migrating the data to a different database.

 

[rob444]

Hi Stan,

If you're operating on a VFP platform that is performing poorly then the program you're running within VFP is written poorly.
Even the strongest "platforms" can be brought down on their knees by writing illmanered programs for it.
So I don't think migrating to "another" platform will solve your problems.
Just let an expert have a look at your VFP program(s) and/or consult the VFP forum here.

Rob.

 

[baltman]

VFP is generally regarded as the fastest PC data engine. I'd agree with Rob that if there is a performance issue that it is a software design or hardware issue.

VFP does have single file 2GB limits, but if your tables don't need to store that much info, then it would probably make sense to let a good VFP programmer look through your current app and see how easy it would be to improve.

Brian

 

[StanKorn]

Thanks for the feedback. Yes, the app is very poorly written and its implementation was not done correctly when it was installed 4 years ago. I am at 2.6 GB of utilization at this point and the company continues to grow which is leading me to a more robust database server as opposed to the VFP or Access environment.
We are generating about 250-300 loads per week and are expecting at least 10% growth over each of the next 3 years which willl increase our transaction volume.
Are there any items that I should pay particular attention to as I enter into this process?
stan


Remember - only dead fish go with the flow.

 

[pweegar]

Sounds like a MS SQL solution here. Both VFP and ACCESS are unferpowered for your situation. Were I work, a a large international company, we use VFP 6 to track boxes. It can be fairly slow, and prone to indexing problems, esp when tables are stored on a Linux system.

With MS SQL (or Oracle for that matter) put as much money into the server storing data as possible. The faster the cpu, the more memory and disk space you have, the happier you will be. Make sure your network is fast also. Users get impatient when they don't see result sets returned quickly. I've seen users reboot their pc because they thought the app had died!! Does wonderful things to indexes if you aren't using transactions, etc.

 

[skiflyer]

Seems to me like your being answered like a developer, but you're asking like a purchaser.

First things first, I agree, scratch access and foxpro.

Secondly, java shouldn't be compared to MS SQL. Java is a language, and MS SQL is a database.... you can very much have a Java & MS SQL solution which works together.

If you're doing this in house, I'd strongly suggest PostgreSQL or MySQL as your database. For your front end, anything from VisualBasic to VisualC++ to Java to PHP to C# to Python to whatever, depending on your developer's skills.

But if you're purchasing, I'd say this much...

1) MS SQL is good stuff, but ask if you're expected to purchase and maintain this on your own. MS SQL is a separate item, and usually not bundled in applications which use it, you will likely be expected to shell out the cash for the database, database server and expertise to get it up and running.
2) Java is nifty, I have some reservations on using it in Windows environments... this comes mostly from personal experience and really slugish applications, if you test out the application and it runs fine for you, please ignore this comment.
3) MS SQL/Oracle/MySQL/PostgreSQL are probably the four database backends you're willing to accept as part of your solution, I could be wrong and missing something, but that's my guess. Whoever the vendor is ask them what your DB backend is going to be, if it's Access, MSDE, FoxPro, or FileMakerPro you're going to swamp it, ask those people if they're programs can be plugged into one of the big boys.
4) You guys sound ripe for a custom application... something written with a free db backend might end up being cheaper than a purchased solution relying on a commercial db, but take that with a grain of salt, custom solutions have all the obvious drawbacks of support and maintainability.

Good luck,
Rob

 

[Dimandja]

Great analysis, skiflyer!