I don't know if this question belongs here or not, someone please move it to an appropriate place if needed.
We are working on a web application using PHP and MySQL. The software is of the sort that provides a lot of pre-fed data to its users. For example, a list of questions and answers like a knowledge base. Now every user who registers into the system would have the liberty to add/update/delete this knowledge base, without affecting the data of the other users.
Now I understand that we would require to have a master copy of this pre-fed data, and would have to make a copy of this data available to users.
I was wondering how to implement this in the system without affecting the performance.
Would we have to create separate databases for each user?
Any pointers?
Thanks!
I find three approaches to this, they'd depend upon your domain requirement.
You're 'seeding' configurations and basic data for which it does make sense (to me) to localize the settings per user. I guess most of the apps follow this.
If it's domain data, when you say knowledge base (which I take to be very huge), it'd make more sense to save the per user edits and merge the master data with a user's personalized data. This is a very abstract & I wouldn't know it's implementation unless I actually see the data modeling, but then this looks a viable approach!
Save edits from all the users separately at one location (per collection or however you wish) if you want collaboration and stuff. With this, I think, it'd be easier to grow your knowledge base, although you can do the same with the previous approach with a little help from DBA!
Related
We have a web application that we're refactoring. We want to make an environment per version with different users (companies) that share the same codebase.
It know this is a somewhat simple question but I just want to make sure we make the right decision (according to webapp best practice).
Say companya.webapp.com points to /1.00/public
and companyb.webapp.com points to /1.30/public
I'm wondering what the best way is to store custom data from these users. Custom data could be uploaded documents, photos and also generated static data like PDF documents/invoices.
When I migrate a user to a different version I want his data to be available in the other version too. The documents also have a record in the database with the path description.
Would it be OK to do something like this structure:
/data/[companyname]/pictures
/data/[companyname]/documents
/data/[companyname]/documents/pdf
/data/[companyname]/documents/csv
/1.00/public
Sure, use whatever structure you like. There's no real "correct" answer, and it's very hard to do it wrong. Just make sure the permissions are properly set, so that each company can't read each other's files.
I've been approached about writing a system for a client. They currently want something to replace the email approach that is currently being used.
The system is fairly simple on the surface. There is my client, who is the customer, and his clients.
His clients need to be able to create new messages which are then saved in a repository so to speak. They can also edit and delete their messages.
My client should be able to view all the messages for him (so he can process them so to speak) and essentially be able to view them, filter them through advanced filters / search criteria, through a smart looking web front-end.
My main experience in this kind of thing is using PHP/MYSQL/Oracle. I can see that it is quite easy to create a system for this using these technologies. One dB, which will have aroound 20,000 records created per year say. Allow access to my client to view, advanced filtering and searching, and to his clients to create, edit and delete.
I'm just wondering if I'm missing anything obvious here, in terms of an off-the-shelf solution? Or should I be considering some other technologies (I pretty much can use anything I have to).
Many thanks,
There are a multitude of options. I don't think any of them is better than the others for your application. I'd go with what you already know, or what you can hire people easily to create/maintain.
I'm looking for the best possible way of sharing model data between two MVC (I'm using Symfony) driven web sites.
Background information
We have two web sites A and B. The same software is used for both sites, but there are different customers and data. Customers are allowed to release content. Now we're going to introduce a new payment option with the advantage that the user's content is released on both web sites automatically.
Implementation ?!
I have three ideas for the implementation:
Using the same database for both applications. Then I would have to extend some tables by one column which indicates the appropriate target web site (A/B).
I think that this would be bad design. A lot of code has to be rewritten in order to exclude records from query result sets, which does not belong to the respective web site.
Using two databases.
In my opinion, this would decrease performance significantly and would be very hard to implement. Data has always to be requested twice. Also, in future there may be web sites C,D,E...
Synchronizing two databases via web-service.
Some data would be stored twice. Therefore, all operations on such a piece of data has to be performed twice (create, read, update, destroy).
Now I'm stuck, because each solution has serious disadvantages.
Do you have any ideas? If not, which one do you think is the best of mine?
I think your first option is the best. You're going to reduce duplicate data as much as possible and you should have the best performance. You will have to add an extra check to exclude the records not belonging to each particular website but all solutions will require work.
Sorry for the confusing title....
We are developing an application to be used by multiple companies. For the most part, the application is the same, your standard sort of database manipulation pages (search pages, edit pages, etc.) customized for the data that it is designed for.
However, each company has a slightly different process, and we will be dealing directly with each company so we'd like to use some sort of system that would allow us to tweak pages depending on which company is viewing the page. For example, one company might want a couple extra fields on a data input page, or another company might want to view a different piece of data on a search results screen, and so on.
I understand this is all hypothetical and I wish I had a concrete example to give you, but honestly the companies haven't even given us very good examples. We just want to be ready.
So my basic question is, what is the most flexible way to allow for these tweaks and customizations on a per-company basis? Obviously, the most flexible but least programmer-friendly way would be to make a complete copy of the app for each company. This obviously isn't an option because we'd need to manage updating code on all the sites, trying to keep them all running and tested and having issues resulting from the customized code.
What are your thoughts on Smarty being a solution to this? Perhaps if we have a master set of templates, but then each company can have a different subfolder with any replacement template files... Of course we'd still need to update a bunch of different template files whenever we change one of them, but it would be a little more localized anyway.
Is there a better way? Some sort of differencing template engine maybe, so that we can still edit the original files and the changes will adapt on top of the originals (kind of like a patch)? Or perhaps we should use the object-oriented features of PHP5 and then use polymorphism? What is your best suggestion, and especially if you've had experience with this sort of thing, what are the options and which have you used and why?
I think the template method pattern will help you out a lot. It's really a great pattern for factoring stuff that is mostly the same but differs in a few places. I'm actually working out a template method hierarchy for my own project right now.
I would suggest you try to create the application either using an mvc framework or using your own implementation of mvc.
In this manner you could create models that could be reused (and also views) for other companies.
I'm currently working on a small webapp where I work. I've created this for different departments. So, for example, let's say that: Marketing, Human Resources, and Sales uses it.
Right now, as it stands, I have 3 completely different directories for each dept:
http://mydomain.com/hr
http://mydomain.com/marketing
http://mydomain.com/sales
And each directory (department) has it's own MySQL database, with it's tables.
I have a few questions so that I can hopefully create this more efficiently:
1) Sometimes, I will have a user who will have access to two or more of the departments. For example, a user might have access to both HR and Marketing. I do not want to have this user create 2 different accounts. How can I "tie" this into one database?
2) Also, if I have a user who has access to both "areas", what would be a good way to 'direct' that user to change between both departments?
3) Finally, regarding the different directories, is there a more efficient way to do this? Each directory is essentially the same exact code, just with minor changes.
This is something that I've never done, so some help on creating this the 'right' way would be great. Especially while it's small, if I eventually expand this out to other departments.
Thanks!
Your company, like every other probably has one place to store all of their employee information. You should apply the same principle on your web application, meaning you should have one central database for all employees with privilegies information so that you can define employee's access to each department.
If you apply the above principle (one database for all users containing privilegies information) it should be pretty easy to redirect users to other departments if that is what you'r asking here.
You should split your project into smaller pieces so that you can identify the core part of your project and share that part among all departments. There are many ways to accomplish this but copy-pasting your code for every department is not efficient and it will get in your way later on. Even with three departments it is tedious to copy-paste changes to each one. Also note that if you use separate databases for departments you wont be able to share data among them (at least not in a nice, elegant way).
What you should do is leave your programming language on side for a couple of hours/days and write some design documents about that project. It doesn't have to be too detailed, just enough so you can see how modular it will be and what you can and shouldn't do to make it more modular.
With that said, you should wait for more answers as I'm not as professional as others on SO :-) And excuse my bad english.