I am working on a large web application project and the previous designer favored the use of ids as handles to form fields over name attributes.
I suppose one advantage of this is that the lookup of that field via Javascript is faster through ids.
A big problem I'm now running into, however, is that ids have global scope. I want to refactor a large set of database column names to a more standard naming scheme, which doesn't include any column name prefix to identify which table the column belongs to. This is going to cause problems in those forms that use ids, since the field ids correspond directly to the column names. Column names which were things like "zon_name" and "pro_name" are now going to both be just "name". This will cause non-unique ids in the html.
So, after that long preamble, here's my question...
Before I try to address this scoping issue by changing all the forms to use name attributes instead of ids, are there any other reasons I'm not considering that the original developer may have had for using ids besides the speediness of their lookup?
I know this is a long one so I appreciate anyone who is brave enough to read through and give a good answer. Thanks!
Name and id do different things and, while there is some overlap, they are not interchangeable for the most important things they do.
Use name
To determine what key will be given to the data when the form is submitted to the server
To create radio groups
From JS/CSS when you need to reference multiple form controls at once (and when adding a class or using the element type is not more appropriate)
Use id
In the for attribute of the control's <label>
From JS/CSS when you need to reference a specific input
I suppose one advantage of this is that the lookup of that field via Javascript is faster through ids.
Not significantly (especially when the name is a unique one).
It sounds like the original designer hasn't been following standard conventions and has come up with something highly JavaScript dependant.
If you're using forms, you should be using <label for="aFormElement"> along with your form elements.
The for attribute on label matches up with an id attribute, not a name attribute.
So, you really need both id (for the label, amongst other things) and name for server-side code.
For the speed to find your elements, you can set just id on the form.
Then for the fields use name to read them like:
var form = document.getElementById('theForm'),
productName = form.productName.value;
Related
We are breaking a large asp.net web forms app into chunks and one of the pieces will be rebuilt using asp.net mvc. There are 2 primary types of orders (lets say types A and B). Each order has secondary types (lets say A1,A2, B1, B2, etc.) and each order has attributes. Type A* orders share almost all of the attributes and Type B* orders share half of all the attributes. From the order history we found most of the orders placed were of Type A. The current design uses user controls for the order form for each secondary order type so there is user control for A1, another for A2, etc. The attributes are fields in these user controls.
As part of the redesign we wanted to see if we can get away from user controls and instead generate the order form with the necessary attributes dynamically while keeping the app lightweight and also be able to add a new secondary order type with minimal effort.
Design 1: Create a table with all possible attributes and map them to each secondary type and turn on/off attributes? It could get very granular and include information about how an attribute should be rendered.
Pros: Adding secondary order type is easy, just need to add mapping for new order type.
Cons: Adding new attributes will requires changes to mapping table and perhaps all the layers. May need an admin section to manage mappings.
Design 2: Use jquery templates to replace user controls, send up json to the server.
Pros: Easy to add new form for a new secondary order type.
Cons: some logic may have to go into the templates (views)
Any advice on which one of these is a good design? Is there a better way?
Thanks.
Your database design has nothing to do with ASP.Net or JQuery. You need to worry about building a solid data model.
Table Inheritance and a good ORM will help here.
http://martinfowler.com/eaaCatalog/singleTableInheritance.html
https://community.jboss.org/wiki/NHibernateForNET
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 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'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'm writing a CMS for various forms and such, and I find I'm creating a lot of drop-downs. I don't really feel like mucking up my database with tons of random key/string value tables for simple drop-downs with 2-4 options that change very infrequently. What do you do to manage this in a responsible way?
This is language-agnostic, but I'm working in Rails, if anyone has specific advice.
We put everything into a single LookUp table in the database, with a column that mapped to an enum that described which lookup it was for (title, country, etc.).
This enabled us to add the flexibility of an "Other, please specify" option in lookup dropdowns. We made a control that encapsulated this, with a property to turn this behaviour on or off on a case-by-case basis.
If the end user picked "Other, please specify", a textbox would appear for them to enter their own value. This would be added to the lookup table, but flagged as an ad hoc item.
The table contained a flag denoting the status of each lookup value: Active, Inactive, AdHoc. Only Active ones would appear in the dropdown; AdHoc ones were those created via the "Other, please specify" option.
An admin page showed the frequency of usage of the AdHoc values, allowing the administrators of the site to promote common popular values into general usage (i.e. changing their Status flag to Active).
This may well be overkill for your app, but it worked really well for ours: the app was basically almost entirely CRUD operations on very business-specific data. We had dozens of lookups throughout the site that the customer wanted to be able to maintain themselves. This gave them total flexibility with no intervention from us.
You cold have one single dropdown table with an extra column to say what the drop down is for... limit the results with a where clause...
At my current position, we implemented a LookupCode table that contains a CodeGroup,Code, and Meaning column, as well as some others (like active). That way you have a single table that contains all of your lookup values are in a single location and you can do some quick lookups to bind to your dropdown lists.