Application Structure Suggestions

  • Thread starter Thread starter Ivan Weiss
  • Start date Start date
I

Ivan Weiss

Okay guys, I have some theory for ya. I am building a program for my
company to manage our products. We are in the foodservice industry and
sell equipment. The models will be stored in my database with there
accompanying electrical / plumbing data etc... Users will add the
models to the project they are working on to specify them for the
project and my program will generate numerous reports. What are
suggestions based on client/server app vs just clients accessing
database directly. I never wrote a client/server app before and am not
sure if that would benefit me or not.

Any suggestions would be appreciated!

-Ivan
 
programs that use a db are always a bit client server (sometimes the server
bit is on the same pc but i don't think you are talking about that), so i
dont really c your problem. If you could explain w you are thinking of a bit
more it would be helpfull.

eric
 
To explain further my current plan is to have less than 10 client
machines connecting to one large database stored on the server (just a
file server no server application). I am going to split up the database
into many tables (since it will be quite large) to help performance.
Each project will have its own table within the database and than there
will be tables for Customers, the project names, Manufacturers,
Products, etc...

What I was wondering is if I am better off writing a server app that
does all of the database manipulation and a client app that requests the
information from the server or asks the server app to add data to the
database.

In other words, instead of my client apps connecting the the database
directly, my server app would to ensure that all changes are made and
not overwritten and to tell all clients to update their data if a
database change was made.

Does that better explain it?

-Ivan
 
Ivan Weiss said:
What I was wondering is if I am better off writing a server app that
does all of the database manipulation and a client app that requests the
information from the server or asks the server app to add data to the
database.
Click to expand...

Hi Ivan... actually your earlier question was clear enough :-) I believe
you will find that a C/S solution will take you considerably longer to
write. It will take longer to design, to write and to debug. There are
some advantages but if your app has 10 users on a local network it is hard
to say if you would realize those advantages.

As you know in a non-C/S solution all the data is fed to the client app for
processing in that machine. It sounds "horrible" when we speak of millions
of records but in practice it isn't bad at all. Systems run this way all
over the world and have done so reliably for decades.

It should be possible to isolate the data retrieval methods such that
eventually (should the need occur) you could change to a C/S format with
less effort. Avoid arbitrarily mixing your data access and UI code for
instance.

Hope this helps,
Tom
 
Basically, what I am worried about is one user opening a project for
editing and another user opening that same project. For now I made a
field in my database to keep track of the status of a project
(open/closed) and my goal is to only allow one user to open a project
for editing at this time (I would allow others to print out reports).
The chances of two users opening the project at the exact same time is
so small that I don't see that being a problem. Is that an effective
architecture or do you have any other suggestions. This is the first
full featured program I ever wrote and really do not know how to go
about starting to create the architecture and designing it.

-Ivan
 
Ivan Weiss said:
Basically, what I am worried about is one user opening a project for
editing and another user opening that same project. For now I made a
field in my database to keep track of the status of a project
(open/closed) and my goal is to only allow one user to open a project
for editing at this time (I would allow others to print out reports).
Click to expand...

You are basically adding a "checkout/checkin" feature. This can be done
with a field in the project table (as you describe) but it can also be done
with a separate table where the project and the user who has it checked out
are maintained. The "ideal" solution depends upon many other criteria
including perhaps how long it will be checked out, if a user can check out
multiple projects and stuff like that.
The chances of two users opening the project at the exact same time is
so small that I don't see that being a problem. Is that an effective
architecture or do you have any other suggestions.
Click to expand...

It honestly doesn't matter if the odds are small or large. If it can happen
and it is important that it doesn't happen then appropriate logic must be
added a) to prevent it or b) to detect that it happened and then to handle
it. Don't roll dice with business apps.
This is the first
full featured program I ever wrote and really do not know how to go
about starting to create the architecture and designing it.
Click to expand...

Well that can be tough. But I would suggest that you put off a C/S solution
for now if you have never written one. The key to not writing the app 5 or
6 times is to spend more time up front designing it. I wrote a book
http://www.leylan.com (see the Writing Applications - Introduction) for the
Clipper language. It is no longer in print and the code wouldn't translate
directly of course but the concepts are the same regardless of the language
you choose.

I stressed prototyping as a way to see if a) the solution would be effective
if it works as designed and b) the program is something you can actually
write. You can mock up several designs much faster than you can code even
one and finding out "this isn't going to work" three months into development
isn't good.

Hope this helps,
Tom
 
Tom,

Thank you for your input that does help. To answer your last point
first I am very confident that I can write this app because technically
it is a re-write of a recently created app that is very similar but
limited in features and VERY buggy. It was an unfinished project and I
am deciding to re-create it on my own time actually. Therefore, I do
have a reference as to structure and functionality and I can use the
"finished" product to make sure it is worth while.

The check-out/check-in feature is exactly it except that I am expecting
users to have proejcts checked out for quite a length of time, possibly
even an entire day because of the scale of these projects. Therefore, I
will provide "read-only" access which will only allow users to print
reports for the project if it is checked-out.

The only problem I have is what if two users simultaneously check-out a
project. But, that is only possible if it is done within a new
nanoseconds so I do not see that being a problem. But, you are right
and logic should handle it. Any suggestions because I do not know how
to go about doing that. When the user checked out the project I was
going to reload the data from the database, ensure it is still open for
check-out, and than update the database immediately. But, like I said
that does provide a small window for two users to do it at the exact
same time, however unlikely.

Does all of this sound like I am headed on the right path? I do expect
this app to take an extreme amount of time to write since I am doing it
on my own.

Thanks Tom!

-Ivan
 
Ivan Weiss said:
When the user checked out the project I was
going to reload the data from the database, ensure it is still open for
check-out, and than update the database immediately. But, like I said
that does provide a small window for two users to do it at the exact
same time, however unlikely.
Click to expand...

That's "closer" to safe but you need "safe." It's a matter of locking the
resource before the update occurs. When one client has obtained a lock the
other clients will be unable to obtain a lock. Another way is to include
the condition in the update command. If you were going to update "lockflag"
for id = 1234 then you would update "lockflag" for id = 1234 and lockflag
not locked. Clearly that isn't SQL but you can translate it. If the
lockflag was changed you would find id = 1234 but you would not find
lockflag open so the update would fail.

If it gets more complicated you can set it up as transaction with rollback.
Does all of this sound like I am headed on the right path? I do expect
this app to take an extreme amount of time to write since I am doing it
on my own.
Click to expand...

Sounds like a good app to write. You have a model to use which helps.
Still take the time to work out what "parts" you'll need so you can build
the parts. Then take the parts and build the app.

Good luck,
Tom
 
Back
Top