I am looking in to creating such a program in the near future. I have no idea where to start. Although I have programming experience, I have never worked with networking or creating a Windows GUI. I've worked with MySQL and PHP but that is the extent of my experience with databases.
The program will have a server and a few clients that may have various versions of Windows. The clients need to be able to read and update the database over the network.
Basically, I'm asking for suggestions on a language to use and most importantly, how to implement the database and networking.
4 replies to this topic
#1
Posted 16 November 2011 - 03:11 PM
|
|
|
#2
Posted 16 November 2011 - 05:16 PM
You can use almost any desktop language, including various flavors of .NET, Delphi/Lazarus, C++ (along with GUI toolkit of choice), etc.
The key is to not get overly focused on the fact that there's a database, but instead look at what the application is doing, and it happens to store it's permanent data in a database on another computer.
The key is to not get overly focused on the fact that there's a database, but instead look at what the application is doing, and it happens to store it's permanent data in a database on another computer.
#3
Posted 20 November 2011 - 09:57 PM
Hi reed,
You may want to visit my tutorials on creating database application with Delphi (also applicable with Lazarus/FreePascal with a some adjustment). They are:
http://forum.codecal...ion-delphi.html
http://forum.codecal...ase-delphi.html
http://forum.codecal...l-datasets.html
You may want to visit my tutorials on creating database application with Delphi (also applicable with Lazarus/FreePascal with a some adjustment). They are:
http://forum.codecal...ion-delphi.html
http://forum.codecal...ase-delphi.html
http://forum.codecal...l-datasets.html
#4
Posted 23 November 2011 - 07:41 AM
WingedPanther said:
The key is to not get overly focused on the fact that there's a database, but instead look at what the application is doing, and it happens to store it's permanent data in a database on another computer.
I would like to have a plan, though, before I even start...
I'm thinking Visual C++ or C#.
I know I was very vague before, so I'd like to elaborate:
-------
The program will be used to track a tournament (add competitor, classify, calculate fees, add scores, compute results, print reports, etc). In most cases, a number of computers will be networked allowing multiple computers to update competitors' data.
It will need to read in a few (hundred?) thousand records of competitors' histories provided by a 'master' file that will be updated every few months, but will only use a few hundred of those records in any given tournament. The database will be held on the server and manipulated by the clients.
-------
The software I hope to replace seems thrown together (dozens of exe's, making users manually change settings in BDE Administrator, complicated, nonintuitive). I don't want to end up with the same (or similar) end result.
-------
Based on that information, can someone please offer suggestions on the best way to go about the database and networking without requiring a thousand add-ons/components?
#5
Posted 23 November 2011 - 08:00 AM
If it's using BDE, it was probably written in older Delphi code or Borland C++. BDE sucks and has stability issues, but was pretty cool in its day. Depending on the choice of database, you may find yourself working with ODBC settings, which can be just as messy. If you're looking to get something working quickly, C# should do the job nicely, unless you're already familiar with Visual C++.
Regarding the data, start by looking at your class diagrams. Major classes will be tables. If a class has a container, the container will be a child table (foreign key constraint). There will be some refinements to handle relationships, but that is going to be a big head start. You want to break your classes down to "primitives", where a "primitive" corresponds to a native DB type of Blob/Clob, datetime, int, float, or string.
The other big thing to do: keep an eye out for potential growth. If you see yourself adding similar columns to a table in the future (season1wins, season1losses, season1ties, season2wins, season2losses, ...), convert it to a child table. Monkeying around with table structure after go-live is a bit of a pain.
Regarding the data, start by looking at your class diagrams. Major classes will be tables. If a class has a container, the container will be a child table (foreign key constraint). There will be some refinements to handle relationships, but that is going to be a big head start. You want to break your classes down to "primitives", where a "primitive" corresponds to a native DB type of Blob/Clob, datetime, int, float, or string.
The other big thing to do: keep an eye out for potential growth. If you see yourself adding similar columns to a table in the future (season1wins, season1losses, season1ties, season2wins, season2losses, ...), convert it to a child table. Monkeying around with table structure after go-live is a bit of a pain.
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users


Sign In
Create Account


Back to top









