I am looking at creating a class that has a set attribute function that can store an attribute into the database. The problem is I don't know what type of attribute people will want to store, I just know that they just want to store different attributes based on user input.
Does anyone know how to do this, or if it is possible?
This depends on whether you want to query for the values or not.
If you don't want to search for the values, you can always pickle the data and store it in a BLOB.
If you want to search (efficiently) for keys and values you have to have as many columns as you have different types and perhaps add a "type" column which tells you which column to use.
Related
I have table and in the images column I am saving the names of the images needed for that row data, I want to know if there is any way to read multiple image name which are in the same column(and row) and fetch corresponding image from the folder.
I can read one image name and fetch that image from the folder, but not more than one.
Do I have to create multiple column to achieve this?
Even of you could, its not a good design to store multiple image names on the same column(not just for images, but any type of data in general), research about "normal forms"(or normalization) in database design, the best approach would be to store them on another table with a 1 to many relationship(the images table would have a foreign key to the original row),this way you can easily fetch image by image with a simple join ,and use the current code "for one image" you already have
Microsoft SQL 2016 have JSON storage support. You could store the names in JSON in a single column and return the result as JSON. Something like:
SELECT a.ImageNames FROM table1 a FOR JSON
Then you could load the JSON into an object with a list property.
Some variation of that. It's difficult to tell because we don't know what language or framework you're using other than MS SQL. But if you want to store multiple values in a single column/row, JSON would be a good way to do it.
You could also just use a simple CSV value.
I'm trying to do it like this:
Every single user can choose fields (like structures on MySQL) where this fields can handle their respective value, it's like doing a DB inside a DB.
But how can I do it using a single table?
(not talking about user accounts etc where I should be able to use a pointer to his own "structure")
Do something like: varchar Key where register something like "Name:asd" where PHP explode : to get the respective structure ('name' in this case) and the respective value? ('asd')
Use BLOB? can someone turn the light on for me? I don't know how to do something where works better than my current explanation...
I know my text is confuse and sorry for any bad english.
EDIT:
Also, they could add multiple keys/"structures" where accepts a new value
And they are not able to see the Database or Tables, they still normal users
My server does not support Postogre
In my opinion you should create two tables.
with the user info
with 3 fields (userid, key and value)
Each user has 1 record in the first table. Each user can have 0 or more records in the second table. This will ensure you can still search the data and that users can easily add more key/value pairs when needed.
Don't start building a database in a database. In this case, since the user makes the field by himself there is no relation between the fields as I understand? In that case it would make sense to take a look at the NoSQL databases since they seem to fit very good for this kind of situations.
Another thing to check is something like:
http://www.postgresql.org/docs/8.4/static/hstore.html
Do not try to build tables like: records, fields, field types etc. That's a bad practice and should not be needed.
For a more specific answer on your wishes we need a bit more info about the data the user is storing.
While i think the rational answer to this question is the one given by PeeHaa, if you really want the data to fit into one table you could try saving a serialized PHP array in one of the fields. Check out serialize and unserialize
Generates a storable representation of a value
This is useful for storing or passing PHP values around without losing
their type and structure.
This method is discouraged as it is not at all scalable.
Use a table with key-value pairs. So three columns:
user id
key ("name")
value ("asd")
Add an index on user id, so that you can query a user's attributes easily. If you wanted to query all users with the same properties, then you could add a second index on key and/or value.
Hope you are using a programming language also to get the data and present them.
You can have a single table which has a varchar field. Then you store the serialized data of the field structure and their value in that field. When you want to get the structure, query the data and De-serialize that varchar field data.
As per my knowledge every programming language supports serialization and De-serialization.
Edited : This is not a scalable option.
I'm developing website in which will be categorized advertisements. In each category will be possible different fields of input (example: for car there will be motor size, for cat there will be a race). So I'm thinking how to build database to manage this (I will use MYSQL database). One way you can see in attached picture, I know that also is solution to create table for each values datatape, but I'm wondering that it will slow down a website. This solution which is in picture will generate empty fields in sp_advertisement_value table what isn't good also.
What is in your opinion the best solution? Maybe there is something else?
p.s. Here is a link to database market.
You can store it like name/value pairs (more or less same to what you is described in the image you attached).
A simple schema would be a table having two columns name and value. Instead of having a column for each data type like value_int, value_string etc. have one single column value who's data type can be varchar (or Text as seems fit to you). You can do all the data conversion in your application code as per your needs.
You can do some normalization here too for instance instead of saving name you can make a separate lookup table named parameters having id, name and other related information and have the parameter_id in the table where you are storing parameter values.
I've been trying to answer a complex Mysql data structure problem for custom fields for an online app. I'm fairly new to Mysql so any input is appreciated.
The current database is a relational database and each user of the service will share the same database and tables.
Here is an example of what I'm trying to do.
Let's say I'm trying to create a list. This list can contain up to 30 custom fields. The user can choose between 12 unique elements and each element can have up to 15 user defined attributes.
Each list can be unique within an account as well as between accounts. Accounts can have numerous lists and each list could have different quantities of elements as well as different attributes per element.
An element can be many things, for example: multiple choice, radio button, phone field, address, single line text, multi-line text, etc.
An example of attributes for a multiple choice (checkbox) element could be: red, green, blue, orange, white, black
An example of a single line text element could be: First Name input field.
Each element must also have a user defined title field and tag field which can be referenced and used in other features of the app.
Segmentation is very important as well. A user needs to be able to segment a list based on any element. For example, a user may want to segment list "ABC" based on all records where "red" is present in multiple choice element #1 (they may have more than 1 multiple choice element for a list).
In this example I would assume that arrays, EAV, Serialized LOB would work fine. However, I'm not sure what would be the best structure for my needs at my scale.
In reality, there will most likely be up to 50,000 records per list and there is a real possibility of 20,000+ accounts - each with numerous lists. Therefore, I'm looking for the most efficient and flexible structure.
To make matters even more complex I also need to ensure an efficient way to add/ delete elements to any particular list at any given time. For example, if a user creates a list with the maximum allow number of custom fields (30) and then three months later decides they want to delete a field, I need a way to find that list and all associated values for that custom field and then delete all the values, element type and its attributes. The user would then be allowed to add a new element to this list.
I've reviewed many of the EAV posts on this site, as well as this http://www.martinfowler.com/eaaCatalog/serializedLOB.html It doesn't seem that EAV would be very efficient for my needs due to the data retrieval downsides.
I was also wondering how well a multi-dimensional array would work at this scale? I believe wordpress uses this for their custom fields.
Any input would be greatly appreciated as to how best to structure the database for this situation. Thank you!
You can read about how FriendFeed implements custom fields:
http://bret.appspot.com/entry/how-friendfeed-uses-mysql
They use a combination of Serialized LOB, with extra tables containing inverted indexes. You don't need an extra table for every possible attribute in your LOB, only the ones you want to search for with assistance from an index.
You can use json enconding and decoding (i'm assuming you're using PHP) to store the input info in a table with a collumn to store the user and other to store this data as text. The answers have to be stored in another table (with a FK to use CASCADE ON DELETE).
If you can specify the max size of the input specification, use a varchar field.
This can't be the best aprouch (need some profiling tests to make sure it's robust enough) but can sure be used.
I want to add dynamic columns in a mysql table but I don't know exactly how.
I want to let the user add some columns (fields) in a thread, eg. let him add a integer field and a value (eg. price: 199) or a string field and a value (eg. name: teddybear).
The user can add as many field/value-pairs as he wants.
I thought I could create a many-to-many table:
thread <-> thread_field <-> field
thread: id, title
thread_field: field_id, thread_id, value
field: id, name
is this a good structure?
But in this way I have to set a specific column type of thread_field.value. either it's an integer or a string. I want to have the possibility to have it dynamic, let the user choose.
How can I do this?
Thanks!
The ugly way:
thread_field: field_id, thread_id, value_text, value_int
where value_text is declared TEXT and value_int is declared INT.
For any given entry, you use only one of the two fields.
This problem comes up very frequently with regards to relational databases. It's part of the definition of a relation that it has a fixed set of attributes, not dynamic attributes.
If you need to allow user-defined attributes in a relational database, the simplest solution is to store a Serialized BLOB such as XML or other semi-structured format (JSON, YAML). You lose the ability to query this efficiently using SQL (unless you use an RDBMS that extends SQL with XML functions and indexes), but you're going to sacrifice many features of the RDBMS no matter how you solve this problem.
Another alternative is to use one of the new non-relational data stores like CouchDB or MongoDB, which makes it easy to extend entities with dynamic, strucutred attributes while remaining somewhat efficient.
You can add the type of data to the 'fields' table and store either a string or a binary object and then convert it to the proper type in your code, you would have to do all the validation in code though.
You could also add other properties to the field such as Optional vs Required value, visibility, etc.
If you intend your user to enter arbitrary key=>value pairs, you might want to look at a vertical table. Something like:
post_id, keyname, keyvalue
1, 'name', 'teddybear'
1, 'price', '1.99'
2, 'colour', 'fuchsia'
78, 'mother', 'Diana'
78, 'father', 'Bob'
78, 'pet', 'Fido'
Each of these key/values is linked the the record (post_id) they were created in. This also works reasonably well when you have a lot of options for the user, but very few will ever be chosen. The cons of this solution include a) you can no longer take advantage of automatic typing and b) index is not as useful since the value types are mixed.
If you have a system where the options are well defined, you should design your tables to fit those options. The pros of automatic typing and indexing usually outweigh the flexibility of changing your apparent data structure on the fly.
Finally it's here MySQL select where JSON field property has value .
Save your data in json column and let mysql do the magic
You shouldn't do it.
Site users has absolutely nothing to do with database structure.
You have to learn how to design database structure properly.
There is not a single site around who uses user-defined dynamic columns in the database.
And I am sure you can manage without it somehow.