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.
Related
We have an older system that's being replaced piecemeal. The people who originally designed it broke US telephone numbers for our clients up into three fields: phone_part_1, phone_part_2, and phone_part_3, corresponding to US Areacodes, Exchanges, and Phone Numbers respectively.
We're transitioning to use a single field, phone_number, to hold all 10 digits. But, because some pieces of the system will continue to reference the older fields, we've been forced to double up for the moment.
I'm wondering if it's possible to use MySQL built-in features to reroute requests for the old fields (both on read and write) to the newer field without having to change the old code (which is in a language nobody here is comfortable in anyhow.) So that:
SELECT phone_part_1 FROM users;
Would end up the same as
SELECT SUBSTRING( phone_number, 1, 3 );
To be clear, I want to do this without manipulating the individual queries. Is it possible? How?
You could define a VIEW:
CREATE VIEW users AS
SELECT SUBSTRING( phone_number, 1, 3 ) AS phone_number, ... FROM real_users;
Then you can query it as if it were a table:
SELECT phone_number FROM users;
But that would require your "real" table to be stored with a distinct table name. You can't make a view with the same name as an existing table.
When you're ready to really replace the table with the new structure, then you can use RENAME TABLE to change tables as a quick action (no table restructure required).
Have you looked into views? A view will take the place of a new table for now, providing a way to have your new structure, but still access the data in the original tables. Once you are ready for your final move, you can implement new tables and do a mass conversion of any remaining data you haven't done yet. Or you can go in reverse, which is what it sounds like you really would prefer.
Create your new table, convert your data, and set up a view that mimics the old structure.
Views in MySQL: http://dev.mysql.com/doc/refman/5.0/en/create-view.html
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 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 have a form with about 500+ fields (it's a 10 page form, different data types). Can you guys please advise me on the best way to store the data from the form? I can create 500 fields in multiple, logically divided tables but that seems a lot (or maybe that's the best way?!) since I have a few of these forms. I am looking into serializing the data and storing in longtext mysql field. That will have its drawbacks (the one I am thinking of is if the customer wants to search individual fields in the future) but it does seem like a pretty fast solution. I will appreciate if you would share you experience with a similar situation.
Presumibly you dont expect the user to fill the form in in a single sitting! So you will need some sort of work flow to store drafts and amend previous copies etc.
Also assuming some parts of the form are optional.
You could either define a set of database tables with a master table to track status, user name etc, and a child table for each optional part of the form.
Or you could define an XML schema which contains all the possible fields in the form etc plus some status information.
If you always process the entire form and dont want to search through your collection of forms then the XML soiution is slightly better as there are some nifty tricks for moving data from XML to HTML forms and back again. If you need to search based on values inside the form then the SQL based solution is preferable.
You may need 500 columns - unless they can be placed in other tables. It can be hard to tell without seeing your requirements.
Serialising it would make one of the advantages of using a database impossible - querying against certain column values.
create table profile_details (
user_id number,
field_name varchar,
field_value varchar
);
Now you are not only not limited by number of fields, you also pretty free to add and remove them as you keep developing and maintaining your app.
select firstname, lastname, zipcode
from profiles p
join profile_details d1 on (p.user_id=d1.user_id)
join profile_details d2 on (p.user_id=d2.user_id)
where d1.field_name='hobby' and d1.field_value='fishing'
and d2.field_name='income' and d2.field_value>cast(250000 as number);
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.