Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I have developed an MS Access database for a company to track data in regards to production of a certain commodity. It has many many tables, forms, reports, etc. These were all done as the user requested, and resemble the users previously used system, mostly printed worksheets and excel workbooks. This has created a central location for all information and has allowed the company to compare data in a new way. I am now looking to do this for other companies, but would like to switch it to a web application.

Here is my question. What is the best way to create unique solutions for individual companies that can have around 100 users each?

I would love to create one site that would serve all parties, but that would ruin the customizable nature of what I am developing. I love the ability to create reports, excel sheets, pdf, graphs, etc with access, but am tired of relying on my customers software, servers, etc.

I have some experience with WAMP, but I am far better at VBA. I was okay at PHP, and was getting a grasp on JavaScript a few years back. I am also trying to decide whether to go with WAMP or LAMP, if web is the best choice. Also, should I try set up one site for all users that after log-in goes to company specific pages, or individual sites for each company? Should I host or use a service?

share|improve this question

closed as not a real question by gnat, Walter, Glenn Nelson, Tim Post, Robert Harvey Dec 6 '12 at 16:25

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. If this question can be reworded to fit the rules in the help center, please edit the question.

Can I make a website that links to customized, user-specific sites? Then can I make it so that it is very browser based, using back, refresh... butttons instead of some internal app that would need to load a java system or something? –  riley3131 Dec 5 '12 at 22:41
How much do you know about OOP, design patterns, etc? I'm not sure if you're more of a data guy who pulled off some app-oriented UI stuff for the first time or more of a generalist dealing with web stuff for the first time. –  Erik Reppen Dec 5 '12 at 23:49
Also I'm only assuming that this data stuff you have in place involves the same commodity and that's the bit you want to re-use, correct? –  Erik Reppen Dec 6 '12 at 0:03

3 Answers 3

One way to go would be with a multitenant application. You would basically build one application that has all of the possible features necessary. Companies that want to use it become "tenants" in the application, and some sort of per-customer configuration would enable/disable features for the customers as necessary (maybe some features are paid-for at an extra amount, or custome features are only available for one customer). User-level configuration could be available too (such as giving users the ability to choose what appears on their dashboard, or login screen or something) by storing a user's configuration settings in a table (or tables).

If you really want them to be able to create their own "features" such as reports, etc... you might need an approach that has a lot of metadata about what is available to them.

share|improve this answer
For now, I will be developing everything for them... no plans to allow them to create their own or modify. The tenant idea has merit, I've never heard of that. –  riley3131 Dec 5 '12 at 22:36
@riley3131: That could certainly help to keep things simpler. –  FrustratedWithFormsDesigner Dec 5 '12 at 22:38

It's a Very Big General Problem

It really depends on just how much flexibility you want. I would normally spit on Sharepoint as a viable option but if you really are highly Microsoft-centric, I would at least look into it as it may save you a lot of the web stuff you would need to learn the years worth of self-training to be able to do really anything you could possibly want to do.


If you're not familiar with Object Oriented Programming, you should get a decent handle on that. And then get a decent handle on MVC (Model, View, Controller) and similar design patterns as it sounds to me like what you have is a big giant generic M-ish type resource and you want to start applying different Vs and Cs to it.

In principle M should really be tailored to a specific organization as it's meant to be all about business logic but people tend to think of it more generally as the pan-data-layer and this still works out from a somewhat helpful pattern perspective.

The idea is this, you have a bunch of specific rules for how to deal with transactions of a specific nature. That's your business logic plain and simple and IMO, all that M should represent.

Then you have your View which is the link between the user and your app. That's where all the input/output happens and your various UI widgets would be built.

C is the controller or app-logic. Many believe this should be a very thin layer that really just sort of passes stuff between M and V. I disagree. This is the app-logic layer. That's where database-related stuff like authentication and user data should really be represented IMO. M isn't about users. It's about transactions and how universal aspects of the business work or in this case the business of handling data for this commodity you've built something around.

The point of separating these things properly is that you can re-use them as assets in different contexts. Where it gets tricky is that MVC predates the web and the web is a little weird because there's this giant HTTP wall to send requests from the brower and receive responses from the server over.

IMO it's better to think of View role on the server side as the component that builds responses that you send to the browser. For actual loading of hyperlinks this might involve building HTML templates but it can also be stuff as basic as sending data to the right ajax request (Ajax put simply is merely an http request that doesn't reload the page automatically). Don't even think about the UI on the server. It doesn't need to control that. Just think in terms of requests and what hand off in terms of data so UI behavior can be established by code that runs in the browser (the JavaScript).

Service Oriented

And that brings us to what's called a heavily service-oriented thick-client architecture. The popular idea back when nobody realized JavaScript is awesome and the 2nd coming and all that and a bag of donuts was to abstract all that messy JS stuff away and do a thin-client approach by which I mean you had all your UI stuff sorted out for you with massive, clumsy, hamfisted, inflexible libraries that built the UI for you, but heaven forbid you wanted to modify anything. In .NET webforms they took it so far as to build and serve files straight out of compiled binary resources so you couldn't even really look at the JavaScript without a browser and then only a minified/difficult-to-read version.

This was messy, inflexible and generally awful. The general gist of modern frameworks is to let the UI stuff get handled on the front end (the browser) and not try to hide how the web works from the developer. In a service-oriented architecture, the client-side asks for data as-needed and decides what to do with it. This makes it a lot easier to modify the UI widget stuff because it doesn't have any dependencies other than the right JS file getting loaded on the page.

The Ideal Approach

So... what am I telling you here? I'm thinking that if you could learn everything you could possibly want to know via a vulcan mind meld, the ideal architecture setup you'd want for this is:

  • Something MVC-ish that makes it easy to re-use your big giant M in its totality and a lot of components you'll likely want to reuse from your Cs, plus a decent templating system to custom-tailor pages.

  • A service-oriented architecture for the server-to-client-side of things where any of your apps can make calls for data operations to happen and for client-side actionable data to get returned or updated in your DBs. Then you can do any widget your client-side skills allow. I imagine it's your re-usable C-bits that actually handle the requests consistently so that would be a big chunk of the re-usable C portion of the app.

Tool Choices

As far as tools, I would personally tend to use the following criteria for stacks/frameworks. The goals in my mind are always security, maintainability, ease-of-modification, and rapid turnaround (but not at expense of flexibility - which always costs more long-term).

  • Am I committing one way of doing things or bust or can I ignore/tell the tool to get out of my when I just want to DIY a portion of something. The latter is preferable.

  • Is it about having something that solved all my problems for me, library style, or is it about solving my own problems fast without sacrificing flexibility tool-set style? jQuery for instance is an awesome. jQuery-UI is a library full of stuff I can usually write better versions of in less time than it takes me to sort out why the pre-fab widget won't let me do something and come up with a workaround. Libraries can be okay, just not the ones that want to get their fingers in every cookie jar like EXTJS on the front end or .NET webforms (which is now generally considered defunct).

  • Is it popular with a fairly active community of people who actually write code well? Do-it-all-for-me solutions tend to always fail on that last criterion which is why I tend to dislike stuff like Sharepoint. Although really it's the CMSes that tend to be a security and maintainability nightmare whereas Sharepoint is probably secure at least.

  • Is it open source? There's nothing wrong with paying for stuff but the problem in software development tools is frequently that you never stop paying and the goals of the software dev tools inevitably get muddled by bad capitalism that wants to do things like lock you into a limited number of technology sets all from the same provider or punish you for trying to not use something they're offering. Open source tends to be lighter-weight, more flexible and written by people who take pride in their work because it's getting peer reviewed by highly opinionated programmers they want to impress rather than pooped out on a deadline with a bunch of crap design decisions that often have more to do with impressing the misguided user's boss than the user. That said, if .NET has appeal to you, .net MVC is perfectly reasonable. There's just better for free that you can develop from any OS, IMO.

But Realistically...

You're either going to need help or you're going to have to sacrifice some of the mad-modifiable designs I get the sense you want here unless you're able to work really hard at it (i.e. you don't have a spouse or dog to piss off). All the details of CSS, HTML, JavaScript and how to make them play together well for instance is something I've been at for over 5 years and am still learning new stuff about in spite of spending a great deal of extracurricular time reading up and geeking out on it. I'm moving towards becoming more of a generalist on the middle-tier but I've barely touched on SQL or establishing database schema in those 5 years.

share|improve this answer

Honestly, what comes as business value from what you are creating is that it is custom software designed to solve the particular goals of your clients. As soon as you try to abstract one company's goals to meet the needs of another, you are asking for trouble. It is a pain to maintain separate applications for each client, but it is generally more practical than being able to develop a "universal" system.

You may choose to use or develop some codebase/framework that serves as a common starting point to build each custom application, but if you are trying to develop the single end-all/be-all report generation for everyone, then you are going to end up with a system that is far to complex configuration-wise to be useful.

share|improve this answer
Yes, that is what I have always thought. However, can I switch to a web based system? How difficult is it to communicate with Microsoft Office, or Office-lie products to export data or create graphs, reports... –  riley3131 Dec 5 '12 at 22:39
@riley3131: If you're doing it on the web, do you need to communicate with MS Office products? Could you not replace Excel forms & macros with a web form that collects input and a back-end code that does all the same calculations on the server in $whateverLanguageYouWant and then display the results in a nice web page UI? OR... do you want to create custom, dynamic MS Office documents based on user input and then send those back to the user? It will really depend on the business model of you and the clients. –  FrustratedWithFormsDesigner Dec 5 '12 at 22:41
A lot of people like to be able to share recent data with outside product vendors or consultants. The usual method for doing this is usually via excel. –  riley3131 Dec 5 '12 at 22:54
I'm sure there's plenty of server-side libraries for converting MS doc formats to non-proprietary data and back again. At very least, CSVs are easy enough to DIY when they're a viable option. –  Erik Reppen Dec 5 '12 at 23:55

Not the answer you're looking for? Browse other questions tagged or ask your own question.