Are there any tutorials out there for adding a "watch this" feature to an online store, so users can see when an item is put on sale for example.
My current setup is in php and mysql and I do not offer this feature but would like to give me customers more control over what they are watching and have the ability to be notified when items are put on sale.
All of the products in the shop are listed in a table with unique prod ids. I was then planning on adding a new table for 'sales' - upon a certain event I would like to automate emails to each user who has added the prod id to their watch-list.
Very similar functionality to ebay's watch item feature -but given the potential scale of the work I want to gauge how easy it will be to implement and maintain before committing to much time/effort to it!
Thanks
JD
No matter what you choose to "watch" the general concept is pretty simple. You have a relational table with the user id and the item id. This table is added to on event (click or form submit, however you choose to do so) Either way it is very easy to implement. If you know how to insert to the database then I need not explain the process.
Then you can either run a search and notify script when a table is modified, or run a cron that checks every minute.
This is so vague it hurts my soul to post it, but ultimately the general concept is simple. log a relation. check every minute to see if the user needs to be notified. end of story.
Now, for a more detailed description or actual code, you may want to narrow down your request. It would help to know if you're using a framework or running straight mysql queries. Can you setup a cron? etc.
I'll update if you provide info sufficient for a clear response.
Related
My application will allow users to like or dislike a product and leave a short feedback. I have to make a functionality which will show graph and produce report based on different time frame, probably it will be yearly, monthly, weekly and daily basis.
I have to show how many users liked or disliked the product on a particular time duration via a chart and generate the report. So my application should able to produce the daily graph of August 2018 or monthly graph of year 2018 of a particular product. The graph should able to reveal how many users liked or disliked the product on daily basis if it is daily graph, Similarly it may be for weekly, monthly or yearly time frame
I am not sure what should be the database structure for this type of application? Here what I have thought so far.
products: id, name, descp...etc // products table
users: id, name, email ...etc // users table
user_reactions: id, user_id(foreign key), product_id(foreign key), action(liked or disliked, tinyint), feedback // user_reactions table
data: id, product_id(foreign key), date(Y-m-d), total_like, total_dislike. // data table, will be used to make graph and report
What, I am thinking is that, I will run a cron job on 23:59:59 every day to count the like and dislike of each product and will add the data in last table, i.e. data table as mentioned above and then will use this data table to make graph and report. I am not sure if this database structure is correct or it have some unseen problem (may be in future?)
Note: My Application will be in PHP and MySQL
Well, There is no right answer to your question. Because an answer to your question is called an opinion based answer. You and I will get enough downvotes for sure . But still, hear me out my friend because I was in your state once.
There is a quote by famous professor Mr. Donald Knuth
Premature optimization is the root of all evil
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
The idea is that you have to start building. as your application progress, you will face troubles, you will face problems with your database, your system might not scale or it can't handle a million requests. But until you hit that problem you don't have to worry about it.
I am not saying that you should go and build a system blindly with an infinite loop, or create a table join which can cause deadlocks. I hope you get my point.
Build a system with your knowledge and understanding. Because there is no one straight way to a problem. build a feature -> you hit an issue -> tweak your app -> and rinse and repeat. One day your own experiences will show you the right path.
From your given description I can't figure out exactly how it will come out, but I am sure it will suffice for your initial days. As you progress, you might find it hard to add new features or add additional constraints, But its another day. wait for it and ask another question.
I hope I have answered your question.
I'm building a web application where several groups have their own page but if they want to modify it, an administrator has to validate it before.
For example, can change to change its logo, post new photo, change their phone number, their name, their location etc... Basically they can edit a value in the database but only if the administrator accepts it. The administrator has to validate every modification because... our customer asked us to.
That's why we have to create a system that could be called "pending queries" management.
At the beginning I thought that keeping the query in the database and executing when an administrator validate it was a good idea, but if we choose this option we can't use PDO to build prepared statements since we have to concatenate string to build our own statement, wich obvious security issues.
Then we thought that we should keep PHP code that calls the right methods (that use PDO) in our database and that we will execute with eval() when the administrator validates it. But again, it seems that using eval() is a very bad idea. As says this Rasmus Lerford's quote : "If eval() is the answer, you're almost certainly asking the
wrong question".
I thought about using eval because I want to call methods that uses PDO to deal with the database.
So, what is the best way to solve this problem ? It seems that there is no safe way to implements it.
Both your ideas are, to be frank, simply weird.
Add a field in a table to tell an approved content from unapproved one.
Here's one possible approach, with an attempt to keep the things organised to an extent, as the system begins to scale:
Create a table called PendingRequests. This will have to have most of the following fields and maybe quite a few more:
(id, request_type, request_contents, reqeust_made_by, request_made_timestamp,
request_approved_by, request_approved_timestamp, ....)
Request_contents is a broad term and it may not just be confined to one column alone. How you gather the data for this column will depend on the front-end environment you provide to the users (WYSIWYG, etc).
Request_approved_by will be NULL when the data is first inserted in the table (i.e. user has made an initial request). This way, you'll know which requests to present in the administration panel. Once an admin approves it, this column will be updated to reflect the id of the admin that approved it and the approved changes could eventually go live.
So far, we've only talked about managing the requests. Once that process is established, then the next question would be to determine how to finally map the approved requests to users. As such, it'd actually require a bit of study of the currently proposed system and its workflow. Though, in short, there may be two school of thoughts:
Method 1:
Create a new table each for everything (logo, phone number, name, etc) that is customisable.
Or
Method 2:
Simply add them as columns in one of your tables (which would essentially be in a 1:1 relationship with the user table, as far as attributes such as logo, name, etc. are concerned).
This brings us to Request_type. This is the field that will hold values / flags for the system to determine which field or table (depending on Method 1 or Method 2) the changes will be incident upon - after an admin has approved the changes.
No matter what requirement or approach it is to go about database management, PHP and PDO are both flexible enough to help write customisable and secure queries.
As an aside, it might be a good idea to maintain a table for history of all the changes / updates made. By now, it should probably be apparent that the number of history tables will once again depend on Method 1 or Method 2.
Hope that helps.
I want to add functionality to a website I am building for a client that allows him to log on to a secure page and add new job listings. He will be the only one modifying this so I don't need to worry about concurrent access or anything like that. At this point I don't even have a database set up for him but I understand that might need to be implemented soon, for other features if not this one.
He doesn't have any knowledge of HTML so I can't just create a template job posting and have him manually fill in the information (although that is also unprofessional, I suppose.) I was planning on just making a simple php/html page where he could put the title of the job along with all details through submission of a form. Once I have that, though, I don't know how to deal with adding that job title to a list of current job postings and also have that link to a new page with all the details of the job.
My memory from early undergraduate classes are hinting that the adding jobs to a list would be object-oriented. However, I can also see something where I would just add the title to an array which the list then dynamically filled from.
Another recommendation I have received is to look into implementing a django/python solution. The problem is I have about a week to work on this and I ahve no python experience. If that is something that would be possible to learn and implement in that time, I will go for it. I just don't want to waste time on something that takes a week or two to learn and then still have nothing implemented.
Basically, I would appreciate a point in the right direction and some reassurance that I am considering all possibilities. If it would be easier to implement some kind of simple wiki, that is another option as well.
Do any of these ideas sound like the right choice? Is there anything I am missing?
I apologize if this is a trivial question but I have stumped myself and would appreciate any help you can offer.
A possible and easy solution would be using an appropriate CMS module, like Job Manager or Resume Submissions and Job Posting for WordPress. I haven't tested them personally, but they should handle everything for you through a Web interface, no coding needed (you should just adapt the WordPress CSS to match the existing client's Website style).
For reference, here's what I would have done in case no such CMS module existed.
Create a database with a table that will hold all job postings. The table should have the following columns: id, title, description, validityDate (names are self-explanatory). Add more if appropriate.
Write a script that queries the database for all current job postings using the following query: SELECT id, title FROM postings WHERE validityDate >= NOW(). To manage database connections, use the PHP PDO extension (look at its page on the PHP manual website for examples). This will return a list of all current job postings. For each result, let the script output HTML code like this: echo "$title<br />$description";, where $id, $title and $description are the variables holding the ID, title and description of the current record.
Write the post.php script that will fetch the details of the job posting with the ID specified in the id parameter.
Write another script where the client will input the details for a new posting into a form. After submission, the script should just insert the data into the table.
I'm new to web development and database design, and I'm kind of stumped as how to best accomplish a simple review system for items.
In the current database schema I have a table, call it tbl_item, that has columns for different properties of items. I want users to be able to review items and associate each review in the tbl_reviews to a particular item.
Of course I have a foreign key set up referencing an id column in tbl_item but I do not know where to go from here. Basically my question is: What should calculate the review average?
Should the application make a SQL call every time a review score is requested for a particular item, where the DB would have to then search through all the tbl_reviews rows to find those with a particular item_id?
(That seems wrong.) Should the DB get involved and have some type of calculated field or view or stored procedure that does the same?
Should I have a new column in tbl_item that has the average score in it and is updated whenever any new review corresponding to a particular item is CRUD'ded?
If it matters, I'm using Yii (PHP) and MySQL.
Basically you're asking about efficiency and math.
Here's what I would do:
Your DB is relational. Good, you got that. Each review has a numerical value? Like 1 - 10?
Say it does for this example.
I would say that upon each review, the review itself is set in the DB as well as a queue in an action table. Something that has the item id and a type of action. In this case review.
You then have a cron running in the background every minute or so checking that action queue and in the event of a new review or set of reviews, you run an algorithm for each applicable item that collects all of the data available on the review and returns an educated number based on the standard deviation of the collective data.
This way the math is not run in realtime by the user or when a review is sent. For all we know you have tons of items and tons of reviews, so real time would be bad if your intelligence script is heavy.
As for standard deviation, I check a large variety of things for anti-spam. I store all userdata, IP, datetime, and anything else I can to make sure it's not just one guy logging in with different accounts reviewing his own things with a 10 rating each time. Can't fall for that.
Plus, if you get 100 10 reviews that look legit and 1 review with a score of 1 you can discount it as a hater and just ignore it in the results.
You have to understand your request is enormous, so code snippets are out of the question here.
What I just explained was like 4 months of work for a huge client and a serious anti-spam calculator.
good luck though
Is there something that has been already developed and is Open Sourced?
I'd like to develop a site that is like:
http://www.swap.com/
What I envisage is that a USER A puts in what they have, dvd's, book's, cd's, etc.
USER A then puts in what they are looking for themselves.
The system then does a check against all the users. It finds that USER B is requesting items thats in USER A's inventory.
So USER A can swap item X for USER B item X.
I just don't want to try (operative word here being try) to reinvent the wheel if its kinda been done before.
Thanks
Hmm... not too hard to code, as dionyziz said it's a very simple SQL query. Since you don't want to recreate anything, I suggest looking into inventory scripts. These are scripts generally used to keep track of a store or business's inventory of items for sale, however if you find one that's designed to manage multiple "stores", then each "user" could be a store with their own "inventory".
A quick search for "open source php inventory script" turned up http://www.phpwares.com/
Not sure if it supports multiple "stores", though.
This can easily be done with an SQL query. SELECT from your whole userbase those items who match your currently logged in user's requests.