Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am wondering if I have a table of whose size and content I dont know, and I want to manipulate its data, is it bad practice to add unique id's to each element?
For example lets say the table is representing information from a database.
Is it bad practice to have
<li id= ${database_element.id}>
A better example using this for loop, this displays a list of elements from a table in a database named files
<g:each in="${files}" var="d">
<a id = "${d.unique_id}" class = "file" href="somelink.com" ><image id = "iconImage" src="img/iconImage"/>
</a>
</g:each>
So now each element of the table has its unique id from the database.
Is this a good or bad idea, especially when it comes to file storage i.e file/folder ids?
The reason I am asking is I cant see any other way of manipulating individual elements of the table without this?
It's usually fine.
There would really need to be some good reason for it to be bad. I'll start a list of things...everybody feel free to add to this list...
There are weird characters in your database IDs and they didn't get converted well or HTML escaped properly.
The same thing as above, but going the other direction (from HTML ids to database IDs).
Your database IDs change for some odd reason, and then you send data back to the database using the old ID.
You pollute your ID namespace with these IDs, and then can't use numbers for other IDs (this could be solved by adding some prefix to your database ids, such as db-).
It really depends on your specific situation and I would just wait until you actually run into a problem before worrying about it.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am working on a project where we decided to use EAV (Entity-attribute-value) model to store category specifications and its values for products.
Please help me in understanding this to design a flexible database in MySQL!
In Entity Value attribute, the attributes and their values are entered as rows instead of columns, and I quote:
The basic idea is to store attributes, and their corresponding values,
as rows in a single table.
Typically the table has at least three columns: entity, attribute, and
value. Though if there is only a single relevant entity, e.g. a table
for application configuration or option settings, the entity column
can be excluded.
So for example, for your case:
model to store category specifications and its values for products,
You can do this
Categories
CategoryId
CategoryName
CategoriesMetadata
Id,
FieldDataType,
FieldName,
FieldDisplayName,
FieldDefaultValue,
Etc ....
This way the user has the ability to define the attributes, their data types, their names, and default values if any. Keep in mind that you might need extra columns, for exmample if you want to define combo boxes or lists, you might need another table to define the lists.
Note that: This model is to complex and you might need to make sure that you really need to go with it and there is no other alternative for your scenarios.
See these links:
Using Database Metadata and its Semantics to Generate Automatic and Dynamic Web Entry Forms.
Planning and Implementing a Metadata-Driven Digital Repository
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am aware that this question is asked before and common solution would be like in this link. Separate tables and use join to get information
How to store multiple emails work, personal etc for one contact in MySQL
I just want ask is there any drawback if i saved comma separated emails, numbers, fax or address . This will also eliminate Joins hence better performance. Thanks in advance
With any database-driven application, it's helpful to ask: "What questions does my application need the database to answer?" In other words, what are the main use cases for querying?
The link you provide is basically an example of normalized relational database architecture. Normal forms are meant to minimize duplicate data and ensure data integrity. Within those "quality-control constraints," query-writing is supposed to be fairly patterned and predictable.
Will you need to know if a contact has duplicate email or phone numbers? If multiple contacts share the same email or contact? If phone1 is missing but phone2 is not missing? If all the phone numbers have international prefixes? Those are all questions that can be answered with a database query. And those queries would be much easier and much more straightforward to write with a normalized database (like the one in the link). With data in a single field of comma-separated values, the queries would be hard, impractical, ugly, or virtually impossible to manage.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am still fairly new to creating rails apps from scratch and would like to know the best way to set them up for efficient queries.
Consider this scenario. You are building a social site that shares books using mysql2 for a database. You start with two models; a user and an author. Both need name attributes; first_name, middle_name, last_name etc.
Would it be more efficient to create a name model where name would be it's own individual table?
Or add name attributes to the individual user and author where the attributes remain as columns?
First, you might consider implementing this using PostgreSQL - there are many, but performance is one of the reasons.
More, you have to think the system you build should be maintainable. Having a separate table for the name can be a very bad idea. Do you plan to add names for all the models you have in that one name table? Sounds weird. What problem do you think you could solve by doing that?
Instead, I think indexes can help you out (https://tomafro.net/2009/08/using-indexes-in-rails-index-your-associations) when it comes to retrieving associations.
And I cannot give you more advices on your data model. This depends on the requirements and future intentions. Are you going to query per model and then retrieve associations? Is there going to be sort of a tagging approach to handle synonyms?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have a question about how big companies manage a database structure, let's say if i have an ecommerce app something like shopify which is the best approach you take:
a) When a new user creates an account a new database with his tables is created specifically for that user (i think if for some reason this database fail the other databases of other users remain working)?
b) When a new user creates an account Instead of create a new database, the app just create a new row in a table for his login and then all the products of all users are in the same table and only the user_id is the difference between one product of a store and another.
Thanks in advance.
Yeah, you should go for the second option (b), for alot of reasons:
1. Most of the data in your database shall be accessible for all users, so you don't want to have the same data stored in multiple places.
2. Sooner or later, you will come up with features where you want to share or link data between different users, etc.
3. Your first choice (a) would be extremely resource consuming compared to the second choice (b).
4. Well, the list can go on and on... :)
Obviously, the second choice - much more efficient and smarter.
Think about the number of the users, let's say 10k for example.
you realy don't want to handle this mass of tables!
I would go with Option B. This will reduce your work load and help in reporting needs down the road. Just make sure you use a robust database design to handle load when writing to database tables.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I like to use tables as it will allow me to organize the data in a better manner. But now inside my application I am using tables to represents different data which can give misleading meaning. for example I am displaying the list of all record in a table such as:-
Then I am also displaying the details of each record in a table where rows will have different context:-
For me the tables seems clear ,, but am I using tables in the right context?. Or usually table rows should represents the same type of objects (for example different organizations, not different properties about an organization )? ?
Well. Most systems show information using tables. Look at any forum software, for instance. In terms of user-friendliness, you could emphasize your header rows on your top table. On your bottom table, you could emphasize the left row (a darker background or stronger font).
In my opinion using tables in this scenery is ok. All data is exhibited in simple and clear way.