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.
Related
I'm and intern and I've been tasked with something I'm pretty unfamiliar with. My manager has requested I create a simple MySQL database using data from an Excel file(s) and I have no idea where to start. I would normally ask someone here for help but everyone seems to be really busy. Basically, the purpose of the database is to see what different object-groups relate to one another so as to keep things standardized. Trying not to go into detail about things not really relevant.
I was asked to first design a schema for the database and then I would get an update on how to implement it. Would I just start by writing queries to create tables? I'm assuming I would need to convert the Excel files to .csv, how do I read this data and send it to the correct table based on Object Type (an attribute of each object, represented in a column)?
I don't want to ask too much right now, but if someone could help me understand what I need to do to get started I would really appreciate it.
Look at the column headers in your spread sheet.
Decide which columns relate to Objects and which columns relate to Groups
The columns that relate to just Objects will become your field names for the Object table. Give this table an ID field so you can uniquely identify each Object.
The columns that relate to the Groups will become field names for a Group table. Give this table an ID field so you can uniquely identify each Group.
Think about if an Object can be in more than one Group - if so you will probably need an Object-Group table. This table would most likely contain an ObjectID and a GroupID.
I am currently building a small crm application. I need each user to be able to define their own custom fields. I am currently building this crm using php and mysql.
Example: I have a "customer" table which has the standard fields: name, phone, address, email, etc. But i want to allow the user (unique session) to add fields that are custom to his/her business which are only accessible to him (not other users). I then want these custom fields to function just like all the other fields in the table (ability to search, send and received data). I am hoping i can accomplish this in mysql and php but am open to any technology or solution that is considered best practice. Thank you for your help.
This can be done by creating a table called "customfields" with the elements "id, fieldname, company_id", then another table that would associate those custom fields with data, eg "customercustomdata: id, customfields_id, customer_id". Associate "ownership" of a field the same way
To create a new custom field, "insert into customfields (fieldname,company_id) values ('Birthday',companyid);"
Does that help?
#Matt H: Is this method considered AEV or just standard relational db?
So because i will have many users in many dif industries that will want to add their own custom fields to a number of different tables (contacts, transactions, events, etc) i am assuming that i would need the customfield table to have a user_fk/id or company fk/id, a related table fk/id, an id, and a field name? Am i on the right track? Then in the need to create a 2nd table to hold the data for each custom field buy having a customfield fk/id, customer fk/id, id and a data field to hold the actual data. Is this correct?
Ok so once i build those two additional tables how do I add them to the contacts table so it looks like one big table for the user, instead of the 3 tables?
Thanks again for you help.
Answer
after much research i have found that most people who wish to accomplish this are using document databases not relational databases.
You could place an extra column for storing string data and store an array describing the contents for custom cells. For example:
$custom = array(
array("field" => "bikesOwned", "value" => 4),
array("field" => "travelled", "value" => 14)
);
then use something like PHPs json_encode to store that data in the extra cell. Then all you would need to do is decode and process the array.
Some people suggesting using the Entity-Attribute-Value design, but before you do, please read Bad CaRMa, a story about an EAV-like design that nearly destroyed a company because it was unmaintainable.
To solve this better, read How FriendFeed uses MySQL to store schema-less data. You can lump all the custom columns into a single BLOB, and store it that way. Then if you want individual attributes to be searchable, create a table for that attribute, that maps values back to the customers table.
I wonder if anyone could offer their advice on this one.
I have some customer data whereby certain fields remain consistent. For example:
'Firstname', 'Lastname', 'Postcode'
These are the important fields and the ones that would be searched against. Over time we may have some additional data for a customer, however it is guaranteed that the fields will differ, therefore we can't indefinitely create more fields in the table to accommodate every possible new field.
I wondered what the options would be of storing the auxiliary date fields, for example would creating one additional field 'AuxData' maybe as a VARCHAR that used a JSON array?
(I am thinking of what I have seen in wordpress in the past)
I'd really appreciate anyone's thoughts on this one!
Many thanks
JAson
You can create an extra column with XML data, usually I would recommend JSON over XML, but MySQL has some special functionality to search trough XML data in fields. See this article for a few examples: http://www.informit.com/articles/article.aspx?p=1019623
There is also another possibility, you could create a new table with 3 columns: [Person_ID, Property, Value] where the primary key would span (Person_ID, Property). This way you can more easily search trough data, and you keep it MySQL instead of XML/JSON. However both options are valid.
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 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.