In my quest for perfection and minimalism, I post this question here to you guys, seeking if there is a better and more alternative option than the one I have.
I have a module with two different templates. Essentially the first is a quiz template, the second is a page that displays the results of the quiz. The quiz is a form whereas the results page is not. On my quiz page, the action for the form is essentially 'module/quizResults?id='.$quizId
Now for the quiz action, I do a db query to retrieve the set of questions that belong to the quiz and then when the post takes place the action that is being called is that of quizResults, out here I must compare the answer options of my user against the correct answer options for the questions of a quiz. Essentially, I have to again query the db to retrieve the set of questions for the quizzes in another db. I feel this is a slight overkill and I am irked.
I think there can be better solutions. I can post back to the same quiz page, but then that demands more complexity on the template as well as the action making things a little murkier.
Any alternatives?
Thanks
There are a few options you could implement to do what your asking, but you need to ask yourself will the added complexity outweigh the minor performance gains, especially if the queries are optimized.
Option #1: Session
When you load the questions from the quiz action, you could add the questions to the user's session, then when the user posts the quiz for the results, simply refer to the questions stored in session.
Option #2: Memcached
Same as above, but instead of storing the questions to the user session, you could store the questions into memcache, so when you calculate the results, instead of making another database query, you pull the questions from the cache layer instead.
You're trying to solve this the wrong way.
Performance is absolute no issue here. But what is an issue is programmer performance. If you have to manually craft each query and pass all the right variables along it's going to take a lot of your time. What you need is a framework that will allow you to build the necessary logic in a quicker way. If you know how to do this perfectly you will make a lot of money, until then you'll have to scratch along just like the rest of us :P
Assuming the submission page should display all-good if all correct, or the incorrect ones if not, I would write a myprojectQuestionValidator and use that in my question form, one for each question/answer. The validator can then check each answer against the correct one in the database. Agreed with Frits, don't worry about performance - that's premature optimization IMO. Break the app into conceptual components, and worry about optimization when you need to.
Related
The problem I'm here to talk about and (ask about of course) is not new. I searched web and stack overflow and I got ideas to many part of this problem (pros and cons) but there is still some part missing in my mind. So I thought it would be a good idea to share in one place (of course it will be more complete with others' ideas) and ask for it.
The problem is clear: "We Want to log every single action of user" - probably when we solve the big problem, smaller ones (like logging only one action would be piece of cake).
First from what I read over the web and stack overflow:
Use DB instead of File: That's a good advice although it always depends on situation. But because of many benefits of DB, in long term and in general, it's the better solution.
DB Layer or Application Layer: Actually it depends. For example If you want really monitor everything(I mean really every single rows that changes in Database, it seems we will have one choice "Using Database Triggers". Although there are many discussions around MySQL that says, triggers slowdown DB and they advised not to use it. So it depends on the level of details you need, you can put your logging system in DB Layer or Application Layer(for exam some common function call $logClass->logThis()).
Use Observers: Clean codes are always better. If you are familiar with observers, you can use them to do things for you when an action is happened so you don't have to add $logClass->logThis() every time a CRUD happens in your application.
What To Log: Simple and short answer is: Based on your needs, but there are some common fields you will need:
user_id (if a unique user ID is available)
timestamp (unix maybe)
ip (not everyone know how to fake it in first place so use it, even faking it give you some insight about user behavior)
action_id (should be predefined actions for better unifying in queries and reports)
object_id (the unique row ID of a record that changes had made on)
action (which my question is about this part)
and etc...
I would appreciate if anyone correct me if I made mistake in any part or add other useful information to this post, so it would become one of good references for other users.
And now my question: How to Store actions?. For better understanding, consider following scenario.
I have a table named "product" and a table named "companies". From the business logic we want to assign products to companies, which we ended up in a table "company_product". Now when a user insert new product and simultaneously assign it's companies, 2 table will be affected (the same goes for delete and update): "product" and "company_product" and we want to know:
what's inserted?
what's deleted?
what's updated to what?
For performance issue and because I don't have enough knowledge about triggers, I want to use logging in Application Layer, so I ended up with this idea that I can, save action fields of database in array or json structure. But as I developed my solution I encountered a problem: How to make this log understandable for non technical users? Because for example I want to save something like this in action field of database when delete(insert) product with id 20:
action : [{id: 20, product_id:2, company_id: 1},{id: 21, product_id:2, company_id: 2}]
And this is not something easy for every one to read and understand. Actually I can use this json more readable and make it something like this:
action : {'Product A Deleted From Company X', 'Product A Deleted From Company Y'}
and save the previous action in technical_action field for further diagnose, But it needs additional works and more query to run for something that is not always needed to be considered(log)
I would appreciate any additional information on this article (I'm definitely sure that there exist other criteria that can be discussed), and answer to my question.
You are actually going to gather details for analytics kind of stuffs.
It will be good if you go for flat tables rather than going to relational tables.
Because if you want to do more analysis your relational table will not be a good choice as it lacks in performance.
I've been working on a web application for a company that assists them with quoting, managing inventory, and running jobs. We believe the app will be useful to other companies in the industry, but there's no way I want to roll out separate instances of the app, so we're making it multi-user (or multi-company might be a better term, as each company has multiple users).
It's built in Codeigniter (wish I had've done it in Rails, too late now though), and I've tried to follow the skinny-controller fat-model approach. I just want to make sure I do the authorisation side of things properly. When a user logs in I'd store the companyID along with the userID in the session. I'm thinking that every table that the user interfaces with should have an additional companyID field (tables accessed indirectly via relationships probably wouldn't need to store the companyID too, tell me if I'm wrong though). Retrieving data seems pretty straight forward, just have an additional where clause in AR to add the company ID to the select, eg $this->db->where('companyID', $companyID). I'm ok with this.
However, what I'd like to know is how to ensure users can only modify data within their own company (in case they send say, a delete request to a random quoteID, using firebug or a similar tool). One way I thought of is to add the same where clause above to every update and delete method in the models as well. This would technically work, but I just wanted to know whether it's the correct way to go about doing it, or if anyone had any other ideas.
Another option would be to check to see if the user's company owned the record prior to modification, but that seems like a double-up on database requests, and I don't really know if there's any benefit to doing it this way.
I'm surprised I couldn't find an answer to this question, I must be searching for the wrong terms :p. But I would appreciate any answers on this topic.
Thanks in advance,
Christian
I'd say you're going about this the correct way. Keeping all of the items in the same tables will allow you to run global statistics as well as localized statistics - so I think this is the better way to go.
I would also say that it would be best to add the where clause you mention to each query (whether it's a get, update, delete. However, I'm not sure you'd want to manually go in and do that for all of your queries. I would suggest you overwrite those methods in your models to add the relevant where clauses. That way, when you call $this->model->get(), you will automatically get the where->($companyID, $userID) clause added to the query.
From the looks of things it looks like this might be a more API type system (as otherwise this is simply a normal user authentication system).
Simple Authentication
Anyway, the best bet I can see for an API is to have two tables, companies and users
in the companies table have an companyID, and password. in the users table link each user to a company.
Then when a user makes a request have them send through the companyID and password with every request.
oauth
The next option, slightly harder to implement, and means that the other end must also setup Oauth authentication is oauth.
But, in my opinion is much nicer overall to use and is a bit more secure.
One way to do it would be with table prefixes. However, if you have a lot of tables already, duplicating them will obviously grow the size of the db rapidly. If you don't have many tables, this should scale. You can set the prefix based on user credentials. See the prefixes section of this page: http://codeigniter.com/user_guide/database/queries.html for more on working with them.
Another option is to not roll out separate instances of the application, but use separate databases. Here is a post on CI forum discussing multiple db's: http://codeigniter.com/forums/viewthread/145901/ Here again you can select the proper db based on user credentials.
The only other option I see is the one you proposed where you add an identifier to the data designating ownership. This should work, but seems kinda scary.
I am writing an application which shows a user one thing to vote on, at a time. I have a MySQL table which contains these things. Right now I have it set up so that upon login, I query my database to get a limited number of these things, and then I use PHP to turn that into an array. After a user submits a vote, the thing they've already voted on is 'unset' from the array. When the new array size is one, I query my database to create a new array.
Is this a 'bad' way to do it? Should I instead just query my database to get a new thing for the user to vote on after every time they submit a vote?
Any help/suggestions appreciated.
This will likely get closed because it's subjective...
IMHO, it's all a matter of how you want it to function. Typically, in standard programming, I suggest loading everything up-front so that once loaded, the user's experience is very smooth and without loading.
In Web programming, however, using AJAX or something similarly asynchronous to dynamically modify/rebuild the array as you need is certainly acceptable, especially if the end result is functioning in a way you're happy with.
Bottom line: Either way will work - it depends on your needs.
Reducing database interactions will typically make your web app perform better. If performance is ever going to be a concern, this could help there. On the other hand it makes the code a bit more complicated, which could impact maintainability in the future.
In the end, it's a trade off. As long as everything is done in a clear and logical way, either approach should be ok.
I need to create a quiz/multiple choice questions with correct answer.
Its basically for vocabulary, so 'A definition will be shown' and then possible Words would be provided.
My previous plan: Select word and meaning from Database, then generate the form for answers and then when user answers move on to next word.
I would be selecting words from database randomly, to keep it different each time. Also, I would be noting down how many times the word was answered correctly or incorrectly. So, that later on I can arrange them according to difficulty also.
My Problem: How do I update to the next question when user answers the question? How do I move on to the next problem, I thought I could do it easily using Jquery but integrating Jquery with PHP is tougher than it seems. I searched for plugins but they basically hard code the question in the JS, I wish to take them out from Database which would be updated as required.
Its a pet project, just so that I can help people practice their Vocabulary. I have implemented the basic design and also developed space for people to Contribute their words. The plans for expansion are vast with many possible directions, later, ranking system, facebook integration, etc. etc. I wish to finish it by the end of this weekend, so that I can move on to other things.
You can see vocabulary.dharamveer.in but you would only get idea about the basic application, not much regarding the problem at hand.
Eagerly awaiting your answers, thank you for help in advance :)
ajax is definitely the way to go with this, use ajax with json to load up your questions and then just have jquery loop through them.
Option 1
If you are creating a set length quiz, you could always create the full quiz off the start. That way you can ensure there are no repeating questions without the need to save anything. Then you can just loop through the whole quiz without making a call for each question.
Option 2
If it's a never ending quiz, then maybe you can do the questions in batches. Then when the user is done the old batch you can send that one back as a parameter and exclude them from the new batch. If your batches are large (for example 50 questions), than it would be at the very least 50 questions until a repeat and that's the worst case. Depending on how many questions you have total, you could end up with multiple batches before a repeat.
I would use Ajax to he the next question. Have another page simply retrieve a single random question and retrieve it with jquery Ajax.
Need some ideas/help on best way to approach a new data system design. Basically, the way this will work is there will be a bunch of different database/tables that will need to be updated on a regular (daily/weekly/monthly) basis with new records.
The people that will be imputing the data will be proficient in excel. The input process will be done via a simple upload form. Then the system needs to add what was imported to the existing data in the databases. There needs to be a "rollback" process that'll reset the database to any day within the last week.
There will be approximatively 30 to 50 different data sources. the main primary interface will be an online search area area. so all of the records need to be indexed/searchable.
Ideas/thoughts on how to best approach this? It needs to be built mostly out of php/mysql.
imputing the data
Typo?
What you are asking takes people with several years formal training to do. Conventionally, the approach would be to draw up a set of requirements, then a set of formal specifications, then the architecture of the system would be designed, then the data design, then the code implementation. There are other approaches which tend to shortcut this. However even in the case of a single table (although it does not necessarily follow that one "simple upload form" corresponds to one table), with a single developer there's a couple of days work before any part of the design could be finalised, the majority of which is finding out what the system is supposed to do. But you've given no indication of the usage nor data complexity of the system.
Also what do you mean by upload? That implies they'll be manipulating the data elsewhere and uploading files rather than inputting values directly.
You can't adequately describe the functionality of a complete system in a 9 line SO post.
You're unlikely to find people here to do your work for free.
You're not going to get the information you're asking for in a S.O. answer.
You seem to be struggling to use the right language to describe the facts you know.
Your question is very vague.