I have one Category List user will select a category from the list if user didn't find a category in the list, then he will select "other" option and it will display a text box there user will enter a new category name. This newly added category will go for approval to Site Admin till then it should be mentioned as "Uncategorised".
So my question is how to achieve this using a mysql table should I create a new table as uncategorized category or should I add one extra column to category table as "isApproved". As the solution should be for both add and edit of new category.
As you described
Admin must approve newly added category.
To acheive that you definitely will have a field status or something like that to check if this category is approved or not. You can simply use that field. If it is not active, it is "Uncategorized.
A more flexible way than adding one isApproved (or rather a more generic name like status) column to your table is to create a whole new temporary table. There are number of reasons why this is the better approach:
You can save diagnostical information like who created this category, when did he create it, and so on.
You separate your logic: An unapproved entry is, simply put, a temporary one. Approving it is nothing more than moving it over to your categories table and thus making it permanent.
Your categories table doesn't get clustered with unnecessary entries.
Related
I have a categories and users table. A user can have many categories and a category can have many users (many to many). However, I also need a feature were users can insert/create their own categories and which is only accessible to the user (category creator) + the defaults categories.
I created a pivot table to handle the many to many relationship, however, I was having difficulty deciding if I need to create another table to handle the custom user categories or just add a user_id on the categories table.
What would be the correct structure I should take/create to handle this.
Thanks.
Given the information you have described, there are two solutions which would be valid: one would be to have a separate table for custom categories, and my preferred solution, would be to have a boolean value on the categories table which indicates whether a category is custom or not. This gives you the following advantages:
Logic applied to the two similar kinds of category remains the same
Other fields which are shared can be kept, in kind
If you wish to convert a custom category to a real category, this then becomes trivial (change the boolean)
You could include a creator id field to identify the person to whom the category applies, alternatively, you might simply designate in-code that custom categories may only have one member.
I want to write a method to save the history of changes in the table. I have three tables (products, articles and categories). When a user makes a change, for example in the product name. I want to display a message at the product, example: User Jack change the name of product with "ball" on the "ball2016."
I came up with that I created new pivot table "history_products" wherein the columns will: "user_id", "products_id", "created_at" and "updated_at". This table will be connected with table products. I want to used this trigger. You think it's a good idea or in a Laravel can do it in an easier way??
a good source/library is revisionable, the following:
VentureCraft/revisionable
Lets say I have a database table containing a list of statuses.
In my apps form, I have a <select> containing options for all of those statuses which a user can select.
Now, lets say there is another table called people which contains a column for status which represents a status that was previously selected from the list of statuses.
And lets say that I have removed a status from my statuses table, but there are still database rows for people with that removed status.
Now in my form, I can no longer pre-select the <select> option for that status because it no longer exists in my statuses table.
So how would I handle this so that it still pre-selects the removed status in the select? Is my only option to have an <input type="text"> and then some type of autocompletion like twitter typeahead? And if so, how would I validate this? Would I check if the status they enter is what is already there and also in the database table statuses?
Any insight would be awesome.
SOLUTION
Since you are using PHP, you could dynamically append the appropriate status value to the end of your list based on the person.
SUGGESTIONS
First, you should be using a foreign key to link the status table to your person table, and not just storing the status string in the person table. Creating this relationship would have kept the referential integrity of your tables and prevented you from deleting current statuses in the first place.
Never delete statuses from your table. If you need to remove a status from the list of active statuses, you should add a bit field to your status table called "IsActive" (or something similar). Then you could query SELECT * FROM status where IsActive=1 for new records while still having all the old values when needed.
A user can submit his data, after login. There is two tables in mysql: items, categories. Categories has a field: user_id, but in item table, there isn't, every item should belongs to a category.
When a user submitting a category, its fine, i get the user id from session, and inserting it.
When he submits an item, i set the category_id for it.
The problem is, the user can simply rewrite the category_id (javascript, on the frontend, click on a category : set the category_id), and submit the item into a category which is not related to him.
Two solutions what i'm thinking (but i haven't made like this):
When the user inserts an item, i check the category relation, and if it's not the user's one, its exit.
Add the user_id field into the items table too (not looking as a good option).
What is the good way or what's the proper/common solution in this case?
Add the user_id field into the items table too
If you already have the user_id in the categories table, and you're certain that each item has a category, then this is unnecessary duplication, as you suspect.
Check the category relation, and if it's not the user's one, its exit.
That's the way to do it - when you read the category id before inserting an item, make sure that category belongs to the user. Simple. I would probably just show_404(), but it's up to you if you want to show a meaningful error message.
Why not create a user_id column in category table. When user tries to submit entry check the user_id, if it is not that user redirect him wherever you want
I'm building a CMS (powered by PHP and MYSQL) with pages and categories. Currently users can create, edit and delete pages/categories. But when a user deletes a category, their pages end up in limbo...because the only way they can view pages is by selecting a category.
I'm thinking of designating a default category that cannot be deleted--for orphaned pages. But how would I go about implementing something like that?
Is there a better solution I'm not aware of? I could use some advice.
If each category has a row in a DB, have a field "is_deletable" (a TINYINT should do) and set that to 0 for the default category. This is more flexible than hard-coding the "default" category in.
Whenever you delete a category, make an UPDATE query for pages in that category, to update the category ID to 0 (which doesn't exist).
Then decide on an Uncategorized category, which will contain all pages with category 0.
A user is able to delete the category because you allow it, if you put some requirements to the deletion of a category (if a page belongs to only one category and that's the category the user wants to delete, don't allow it), then they wouldn't be able to delete it.