Maximum PC

I'm not really looking for a specific answer to this, but more people's opinion.

I need to construct a program for the place where I work to track daily sales for various departments within the store.

I'm stuck between writing a web site (using PHP and MySQL that could be either run from a website or on a PC with the proper software installed) or writing a fully-fledged Windows application that would have to be installed.

I'm tempted by the application route, because it doesn't require extra configuration of a HTTP server, MySQL server, and such, but I'm worried that since everything is now moving to the Web, that writing a desktop app may be short lived (and that I will have to re-do it for the web at a later time).

The problem with the web version is that I cannot figure out how to store multiple numerical values to a MySQL database and not have it look like a pile of crap.


Basically, what I need to store is this: a dept number, a sales figure, and a date (366 times, one entry per day). So, 366 records. Then, I need to do this for the number of departments I have (which is currently 10 of them). So, in all, I need 3660 entries that contain a dept number, date, and sales figure (floating point number). How can I create this in a mysql database and not have it look like crap and be clunky??

Suggestions?

You could always go for a Windows app that doesn't need installation.

For the table structure, I'd suggest a department table, and a daily sales table.

Also, have you checked sourceforge to see if there's an OSS application already written that you could use?

Really there is no right or wrong answer. You could go either way.

Windows apps don't HAVE to be installed.

Also, desktop applications are not going to be going away anytime soon. Forget that "web 2.0" buzz crap. It has its place but honestly desktop applications will be around for the very foreseeable future.

Couple of technical questions here:

Is what you are doing with MySQL going to be used to trend data or is it going to be used as a data entry backend? If you are going to need to slice and dice the data over distinct periods of time then this becomes a data warehouse application and denormalization rules will apply to your scenario. If it is going to be used to gather data from a data entry front end applying some type of business logic on the way to the database then you are looking at more of an On Line Transactional Processing database where data normalization and the ACID test will rule the day. MySQL can handle both very well but implementation rules up front are crucial and you need to know going in what your database should look like when it has been implemented.

Secondly, how much traffic are you expecting this application to see? Just three of four users and one administrator to control the fires? Or will this be a company wide application that every employee will be using and will or potentially could become an mission critical application?

If its something quick and dirty for a few users then you will need less concentration on overall design. If it is or may become a mission critical app then other rules may come into focus that will affect the performance and or implementation of said application.

Lastly what is your time budget/monetary budget to get this done in? Get it done asap is always what my boss tells me, but my design docs always specify a project KO date and a drop dead date. If this is an application that is going to see a lot of traffic and will be used all over the place in your company then a web application may be your best bet. If its something that will see a limited user base and will need little in the maintenance cycle then a desktop application that can be installed/uninstalled/reinstalled at will may be more palatable.

The "program" is to track sales data history and provide reports based on that data. For example, they would like to be able to compare sales from today from this same day last year, and do a comparison from that. They'd also like to be able to compare week to week from this year to last year (week to week), and so on.

It's more for projections and analysis than anything else. My thought is that only about 5 users (at any given time) will need to access the data, but I sort of like the idea of SQL and letting a database engine take care of the dirty work while I can focus on the front end user interface, etc.

The only big issue I can see here is security reasons... the store may not want its data even stored on a single computer like that (most people assume that if you have to use IE or Firefox to access something, even if its on your local computer, that the rest of the world can see it).

The only problem I can see with a Windows app is compatibility (since most stores may have older equipment, while some may have brand new hardware, etc).

I mean (for example) Apache, PHP, and MySQL will all work on an older Pentium 3 machine running like Windows 2000 or something. Whereas if I use Visual Studio.Net (like version 2008) it may not be as compatible with older machines (like those that may still be running Windows 2000).

Go with web. Easier to deploy, only a single instance needs to be managed, security can be implemented on the app itself. Trust me on this one: deploying software blows chunks. Web apps have the advantage of not having to manage multiple instances of the same thing or having to deal with versioning. The app seems like a basic data entry with reporting, the web is suitable for that.




I find this statement troubling. The structure of any database doesn't matter whether or not it's a web or desktop application (I know, I've written for both). Values in the database appears nebulous but that's what reporting is all about: you take your assumptions and you massage the data to display in a format that suits the user. No matter how under/over normalized your schema is, you still need to massage the data to make it fit what the user is looking for.



This, my friend, is where you'll need to do research. I'm gathering that you don't have much experience developing databases? Your best bet is to figure out the table relationships. In your case, Departments have sales figures. So you can have a table w/ only departments and a table w/ the sales figures that contain the ID of the Department for the Sales figure of that day. Also, I think MySQL has a decimal type, use that instead of floats (floats determines precision whereas decimal deals with money/currency types - you don't get that weird rounding issue too).

This is not 100% true. ClickOnce btw is amazing.

Truth! You can always change from one platform to another with the same DB model.

True, but hardly anyone uses ClickOnce. I totally forgot about ClickOnce, which goes to show how frequently I use.



You sure can. The only thing I don't like is migrating from DB system to another...that and migrating code from one language to another.

I use it quite a bit myself. It is amazing.

I've used ClickOnce, once a while back. I never really got around to it because web apps took off and I managed/developed for a series of web apps and became very comfortable with the model. Also, telerik has a VERY robust ASP.NET control toolkit that I just adore and use on a daily basis.