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
Related
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 2 years ago.
Improve this question
I have an EER diagram of the hospital database. I am currently working on the normalization process.
As I understand the partial dependency is when an attribute is dependent on only the part of the composite primary key. And this should be removed.
I've applied the rules on my database but still want to make sure that these tables doesn't include partial dependency.
In examinationo table the composite key consists of inpatient_no, doct_no and lab_no. In my opinion diagnosis and conducted_test attributes depend on all three of them. Is this correct?
This table has composite key of inpatient_no, doct_no and surgery_no. The attributes date and time convey information when the inpatient will undergo the surgery. Is this a partial dependncy?
I'm very new to databases, so my quesitions can be quite easy.
It looks to me like your table called inpatient_undergoes_surgery represents an entity, in this case an event. The table has one row for each surgical appointment. It has date and time as attributes. It also has one-to-one relationships to an inpatient, doctor, and surgery.
This table appears to be normalized to me. The others might not be. In particular, it's possible that your surgery table duplicates the information in this table.
Pro tip It's best to use a DATETIME or TIMESTAMP data type to represent the kind of date and time in your table. There's no need to use separate columns for date and time. Understanding that the date and time taken together are actually a single attribute of your entity helps clarify your design process.
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 7 years ago.
Improve this question
I have a website with 4 translation (That is Arabic with 4 different Persian translation), and I had exported each of these translations to different tables.
Which one of these ways are faster and better:
1- Merging or Importing all of this translation (tables) to one table,
and name it nahj_all and adding a flag field to table to clarify
what translation is it (for example flag with numbers 1, 2, 3 and
4).
OR
2- Importing each translation to different tables and get diffrent
name to them according to translation name (or number), for example
nahj_feiz, nahj_jafari, nahj_dashti, nahj_shahidi
I have these tables in MySql and I want to convert database to sqlite
Which one is better for sqllite?
Which way is better for MySql?
Your first approach would be the more standard way to handle multiple languages. Putting the information in one table has several advantages. Notably, the same query can be written for all languages, the only change being a change to a parameter.
It is also easier to maintain a single table of translations, as opposed to multiple tables. And, you can readily see what languages are available, and to add new languages as well.
Having a separate column for each language is generally a bad idea. Although good for presentation purposes, it makes it hard to add a new language.
For MySQL its better to have 1 table with multiple columns:
Something like this :
Language key | feiz | jafari | dashti | shahidi
Then select translation from the language key with the user selected language.
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 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 8 years ago.
Improve this question
I have a table that will hold 'game stats'. The name of the stats that are held are going to be changing depending on which sport the stats are for.
Is best practice to make two tables: one for the stats with columns such as 'Stat1, Stat2' etc. and another one holding the titles with the sportID as a key. Or would the best practise to have several tables for resorts for each sport. Or any other way?
Thanks,
I agree with andy. A generic-titled column like Stat1 - where the purpose is unspecified in the column name, is used polymorphically, or the column type must be made more generic - usually indicates a poor SQL/RA design.
Consider if this were encountered: create table people (field1 varchar(20), field2 varchar(20)). Yeah - not going to fly in my database. Give the columns (and tables) names that mean something in relation to purpose.
Instead, each different type of information collected should have it's own entity (read: table) or group of related entities. In this case I would imagine that each sport represents a different type of collected stats/information. (Even Win/Loss information can vary by sport.)
Trying to "label" columns based on an additional table is a half-way attempt of an Entity-Attribute-Value (EAV) model. While an EAV can be useful it comes with a lot of downsides in SQL and should not be used except after very careful consideration for a specific use-case. (I do not believe that EAV fits this scenario appropriately.)
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I'm using MYSQL to store data about user orders. Using PayPal, some orders have only a transaction ID, and others have only a profile ID. Is it poor database design to have separate fields for txn_id and profile_id, where one or the other is NULL depending on the order?
No, that is not poor design at all.
You have a situation where one or the other is NULL depending on the context. The problem arises when you try to enforce that exactly one is NULL or at least one is not NULL. To do that effectively, you will need to use a trigger to check the values.
If there is always only one id or the other, you might consider having two fields, one is something like id_type and the other is id_value (if they are of the same data type).
This might make querying simpler down the line.
You have two options basically:
Two fields, one for Transaction and one for Profile
One field for both Transaction and Profile and have another field to identify whether is a Transction ID or a Profile ID
I prefer No. 1 (which basically the same as yours) because you maintained the proper naming of the field and not a generic one. And besides you could always use COALESCE() or that kind of function to retrieve the not NULL one if either is NULL.
On that regard it means also that you should have a artificial primary key that would not rely on either Transction ID or Profile ID.