It sounds like your design is to have each client update the mysql db
or flat file when text is entered. The clients would then
periodically query the db or read the file to check for updates.
The advantage of this design is simplicity. The main disadvantage is
scalability. You are rigth that maining a connection does improve
performance, but ultimately you still have n clients polling a
database. Contrast this again a chat server design that where each
client connects to the server, who maintains the chat state for each
client. When a client sends a new messages, the server pushes down
the messages to all the other clients that are part of the current
chat session. The server could also have a thread that maintains a
connection to a database (or file) to keep the chat state stored.
This is considerably more complicated to implement.
As to the question of whether to use a flat file vs a database in the
original design, I would probably go with the database. You are right
that a flat file is much harder to manage. You need to implement the
locking semantics on your own. Mysql is a pretty simple database. I
don't think the performace will be much worse than a file. I would
say that a good rule of thumb is not avoid premature optimization, or
as Knuth might say "Premature optimization is the root of all evil".
What you should do is try to encapsulate the chat state code as much
as possible so that if you do find you need to swap out the db code
for flat file management, you can do without having to modify any
other code. The simplest way to do this is with inheritence. An
abstract class defines the interface. The rest of the code knows only
about the interface, not the implementations. If you switch from a db
implementation to a file implementations, the rest of the code is
unaffected because all of that is hidden from it. A better way to do
it is to use the bridge design pattern, but that is probably overkill
unless you just want to do it for the exercise. |
