Hi I have a table structure as
skills
id
name
users
id
name
and many to many relation
skill_user
skill_id
user_id
different users will have different skill which they will select from skills table thats fine. My problem is that there will be few custom skills(custom attributes) that user will fill in a blank text box. How do i manage this kind of problem please help. I am doing this is php/Laravel/Mysql
You can attach multiple values like this:
$user->skill()->attach($request->get('id'),array('customskill' => $request->get('customskill')));
From another question of mine:
What I need to achieve is this: Create multiple categories with their
own designated information fields (ie. Cars have different fields from
Pets) and once such a category is created, the commands I need will be
invoked and a new table for each category will be made. I know I could
store all fields as some sort of string and then process it to display
it properly, but I need a advanced search function for my web app and
creating separate tables for each category seems the best way to
achieve it. I would really like to hear alternatives for this
So I have this situation where I need categories to hold all input fields needed for that certain category. So in administration I'd have this form where I'd be able to add the category name, some other relevant information to the category itself, and then these fields that would collect information on what HTML fields to present to the user when making an entry to this certain category.
For example this would be a Dog category:
Category name: Dog
Category enabled: 1
Category parent: Pets
Fields:
Title - text field (will be auto added to each category)
Breed - select field
Age - number field
Color - text field
Price - number field (will be auto added to each category)
Description - text area field (will be auto added to each category)
So now at this stage when the user created all these certain fields for the Dog category, Im having trouble figuring what would happen when the user hits the submit button to save this category. I thought of these two solutions:
Create a new model/table for each new category (Read linked question above) with all the HTML fields as columns and also store a row on the categories table with some basic info about this category
Store everything in the categories table and have a fields_json column which will store all HTML field information (I wont be actually storing HTML, but basic info what the fields are about then create the HTML form fields dynamically in a controller) as a JSON string. I would be able to present the fields nicely on create, but on update it would be a hassle to populate those fields (maybe) and a search function would not be very efficient with this alternative.
So what I'm looking for is a third alternative so I can fix my problem. What would be an efficient way to solve this problem and be able to have categories with different input fields and also be able to efficiently perform searches on these categories?
The project I'm working on is being created in Ruby on Rails 4 and the database is in MySQL.
For given scenario I would:
create table categories to store each category
create table category_fields to store each category field
create table collected_categories to store all collected data from category fields in serialized hash
Collected data can be easily (de)serialized into text column (no matter of db engine you will use).
Check those sources which utilize your problem: dynamic forms
I have a model with name Category.
I got user_id and category_id my UserCategory model.
I want to select all Categories which does not have a particular user_id.
How to do this.?
I need to make a dropdown list which do not show the Categories that the user selected before, which gets saved in UserCategory model.
In general, ActiveRecord has built-in support for NOT conditions:
Category.where.not(user_id: id)
For a many-to-many situation, given Category and User:
Category.where.not(id: current_user.categories.pluck(:id))
This will grab all categories, excluding the current user's categories by ID.
I am about to start developing a classified web application. but I am facing certain difficulties
while building the DB design:
User can post their advertisements under different types of pre-existing catagories (like Vehicles, Real Estate, Computers, Education etc). But each category have their certain specific fields/properties as well as some common fields/properties.
My difficulties is like after filling a post Ad, say for Bike, I am saving the common i/p values to my advertisement_t table (as below).
but where will I store other fields values specific to Bike like: Bike Manufacture, Bike Model, Bike Year etc?
same way, if a user wanted to post an advertisement for House(rent), I can save the common i/p values to my advertisement_t table.
but where will I store other fields values specific to House For Rent like: total area(sq), No of Rooms, etc. and how will I map.
My Tables are below:
category_id
------------
(catId, parentCatId, cat_title, cat_desc)
advertisement_t
----------------
(adId, catId, userId, ad_title, ad_desc, photoId, postDate, statusId, price, ad_address, adValidFrom, adValidTo, adIsDeleted)
Photo_t
--------
(photoId, primary_photo, sec_photo1, sec_photo_2, sec_photo_3)
user_t
-------
(userId, username, password, email, activationkey, isvalidated, joinedDate, activatedDate, statusId)
I dont have any idea how other classified sites(like olx, freeadds) used to maintain(persist & display) their posted advertisement data on their database.
If any one has any idea, please help.
Thanks in advance.
I usually like classify these data into 2 groups (1) searchable data which will be saved in some column/mapped to column and (2) junk data( i call that additional_info) saved in a text column in json_encoded format.
For searchable columns, you can add another table category_values table, which has
(category_id, category_value, ad_id)
Again, if your DB is expected to grow huge with category type repeating often, you can break the category_values table to two as
(value_id, Category_id, category_value) and (value_id, ad_id). This results in more joins and need not be introduced in you case I believe.
I did something close to this Once.
And I can see 2 options:
Something you shouldn't do - Implement lots of tables for the required Goods (Houses, Cars, Bikes,..) which is not a very good idea because work would never end and it wouldn't be extensible.
My suggestion:
Add 3 more tables:
CustomField (To set a list of possible fields used by categories)
(CFid, Title)
CategoryCField (Associative relation to know what fields to display when user enters a new ad)
(catId, CFid)
StoredCFData (Actually store the Data)
(id, adId, CFid, value)
You can find however 2 problems doing it this way. Making a "relation circle" which is not very good, but if carefully done will do the work. And having to reduce the DataType of costum fields to text/numbers to make it simple. You'll have troubles applying it to Radio buttons or Combo Boxes.
Best Luck,
Raul
In Meetup.com, when you join a meetup group, you are usually required to complete a profile for that particular group. For example, if you join a movie meetup group, you may need to list the genres of movies you enjoy, etc.
I'm building a similar application, wherein users can join various groups and complete different profile details for each group. Assume the 2 possibilities:
Users can create their own groups and define what details to ask users that join that group (so, something a bit dynamic -- perhaps suggesting that at least an EAV design is required)
The developer decides now which groups to create and specify what details to ask users who join that group (meaning that the profile details will be predefined and "hard coded" into the system)
What's the best way to model such data?
More elaborate example:
The "Movie Goers" group request their members to specify the following:
Name
Birthdate (to be used to compute member's age)
Gender (must select from "male" or "female")
Favorite Genres (must select 1 or more from a list of specified genres)
The "Extreme Sports" group request their member to specify the following:
Name
Description of Activities Enjoyed (narrative form)
Postal Code
The bottom line is that each group may require different details from members joining their group. Ideally, I would like anyone to create a group (ala MeetUp.com). However, I also need the ability to query for members fairly well (e.g. find all women movie goers between the ages of 25 and 30).
For something like this....you'd want maximum normalization, so you wouldn't have duplicate data anywhere. Because your user-defined tables could possibly contain the same type of record, I think that you might have to go above 3NF for this.
My suggestion would be this - explode your tables so that you have something close to 6NF with EAV, so that each question that users must answer will have its own table. Then, your user-created tables will all reference one of your question tables. This avoids the duplication of data issue. (For instance, you don't want an entry in the "MovieGoers" group with the name "John Brown" and one in the "Extreme Sports" group with the name "Johnny B." for the same user; you also don't want his "what is your favorite color" answer to be "Blue" in one group and "Red" in another. Any data that can span across groups, like common questions, would be normalized in this form.)
The main drawback to this is that you'd end up with a lot of tables, and you'd probably want to create views for your statistical queries. However, in terms of pure data integrity, this would work well.
Note that you could probably get away with only factoring out the common fields, if you really wanted to. Examples of common fields would include Name, Location, Gender, and others; you could also do the same for common questions, like "what is your favorite color" or "do you have pets" or something to that extent. Group-specific questions that don't span across groups could be stored in a separate table for that group, un-exploded. I wouldn't advise this because it wouldn't be as flexible as the pure 6NF option and you run the risk of duplication (how do you predetermine which questions won't be common questions?) but if you really wanted to, you could do this.
There's a good question about 6NF here: Would like to Understand 6NF with an Example
I hope that made some sense and I hope it helps. If you have any questions, leave a comment.
Really, this is exactly a problem for which SQL is not a right solution. Forget normalization. This is exactly the job for NoSQL document stores. Every user as a document, having some essential fields like id, name, pwd etc. And every group adds possibility to add some fields. Unique fields can have names group-id-prefixed, shared fields (that grasp some more general concept) can have that field name free.
Except users (and groups) then you will have field descriptions with name, type, possible values, ... which is also very good for a document store.
If you use key-value document store from the beginning, you gain this freeform possibility of structuring your data plus querying them (though not by SQL, but by the means this or that NoSQL database provides).
First i'd like to note that the following structure is just a basis to your DB and you will need to expand/reduce it.
There are the following entities in DB:
user (just user)
group (any group)
template (list of requirement united into template to simplify assignment)
requirement (single requirement. For example: date of birth, gender, favorite sport)
"Modeling":
**User**
user_id
user_name
**Group**
name
group_id
user_group
user_id (FK)
group_id (FK)
**requirement**:
requirement_id
requirement_name
requirement_type (FK) (means the type: combo, free string, date) - should refers to dictionary)
**template**
template_id
template_name
**template_requirement**
r_id (FK)
t_id (FK)
The next step is to model appropriate schema for storing restrictions, i.e. validating rule for any requirement in any template. We have to separate it because for different groups the same restrictions can be different (for example: "age"). You can use the following table:
**restrictions**
group_id
template_id
requirement_id (should be here as template_id because the same requirement can exists in different templates and any group can consists of many templates)
restriction_type (FK) (points to another dict: value, length, regexp, at_least_one_value_choosed and so on)
So, as i said it is the basis. You can feel free to simplify this schema (wipe out tables, multiple templates for group). Or you can make it more general adding opportunity to create and publish temaplate, requirements and so on.
Hope you find this idea useful
You could save such data as JSON or XML (Structure, Data)
User Table
Userid
Username
Password
Groups -> JSON Array of all Groups
GroupStructure Table
Groupid
Groupname
Groupstructure -> JSON Structure (with specified Fields)
GroupData Table
Userid
Groupid
Groupdata -> JSON Data
I think this covers most of your constraints:
users
user_id, user_name, password, birth_date, gender
1, Robert Jones, *****, 2011-11-11, M
group
group_id, group_name
1, Movie Goers
2, Extreme Sports
group_membership
user_id, group_id
1, 1
1, 2
group_data
group_data_id, group_id, group_data_name
1, 1, Favorite Genres
2, 2, Favorite Activities
group_data_value
id, group_data_id, group_data_value
1,1,Comedy
2,1,Sci-Fi
3,1,Documentaries
4,2,Extreme Cage Fighting
5,2,Naked Extreme Bike Riding
user_group_data
user_id, group_id, group_data_id, group_data_value_id
1,1,1,1
1,1,1,2
1,2,2,4
1,2,2,5
I've had similar issues to this. I'm not sure if this would be the best recommendation for your specific situation but consider this.
Provide a means of storing data as XML, or JSON, or some other format that delimits the data, but basically stores it in field that has no specific format.
Provide a way to store the definition of that data
Provide a lookup/index table for the data.
This is a combination of techniques indicated already.
Essentially, you would create some interface to your clients to create a "form" for what they want saved. This form would indicated what pieces of information they want from the user. It would also indicate what pieces of information you want to search on.
Save this information to the definition table.
The definition table is then used to describe the user interface for entering data.
Once user data is entered, save the data (as xml or whatever) to one table with a unique id. At the same time, another table will be populated as an index with
id where the xml data was saved
name of field data is stored in
value of field data stored.
id of data definition.
now when a search commences, there should be no issue in searching for the information in the index table by name, value and definition id and getting back the id of the xml/json (or whatever) data you stored in the table that the data form was stored.
That data should be transformable once it is retrieved.
I was seriously sketchy on the details here, I hope this is enough of an answer to get you started. If you would like any explanation or additional details, let me know and I'll be happy to help.
if you're not stuck to mysql, i suggest you to use postgresql which provides build-in array datatypes.
you can define a define an array of varchar field to store group specific fields, in your groups table. to store values you can do the same in the membership table.
comparing to string parsing based xml types, this array approach will be really fast.
if you dont like array approach you can check out xml datatypes and an optional hstore datatype which is a key-value store.