I want to create a site in PHP with cakephp that users can insert product manually.
The problem is for the multilanguage because I can have into my site users from all over the world and the product 'apple' in italian for example is 'mela'.
Consider that I can have many many data!
Then i have some solution for the database:
Create a table products with an id
Create a table product_aliases where I have an id the id of product language and the text(ex. apple)
In this mode users can enter into 'apple', translate ad I insert a new line into product_aliases with same id product different language and different text but same product
Define 5 language and create a table with more fields (title_en, title_it, title_es...) the translation is in the same record
Only one table but restricted language
Create a table products with an id
Create a table for every language that i want for example: prducts_en, products_it where I can store my data with same foreign key to the product but divide from language to make fast query.
Other solution are accepted!!
I never work with large multilanguage database help me and tell me what is the best solution for my database
The first one is the correct solution in general.
It's used in many enterprise applications: a table with an id field for identification of the not multilanguage information (example: unit price for a product) and a table with a row for every combination product/language.
The second one is against every db normalization rule.
The third one is a different derivation of the second one, and if you use an index on the language column in the translated labels table you should not have a great disadvantage in terms of performance.
If you need I will explain better!
Related
This is a fictitious example to try to illustrate some design choices I have...any thoughts or links deeply appreciated.
Imagine we have a MySQL database with a table (call it libTBL) that contains a row for each book in a library.
This table will be updated, by admins, as new books are added.
Users will be able to create a library of such books - that is, a list representing THEIR selected books.
Users can add a personal, private comment to each book and other meta data (when they started reading it, a review etc).
Users can also add their own books, but these books should not appear in the libTBL table.
What are best practices for capturing this user data?
When a user is created, create a row in a new table, with each book in the libTBL represented, so IF the user adds notes or other data we already have a home for it?
Create a new row in a user library table only when they make a note on a specific book?
-- One use case, though, is a user ordering their subset library...which would require a new row for each book they order (or all of them, depending on how ordering was implemented).
Use bookID and userID to query a user table for custom values for a particular book?
Given a string of text as search criteria, in every field in a (very large, 50+ columns) table.
there is one main table and many smaller ones that are connected to it, but have 'ids' in the main table, not actual searchable text values.
such as:
TABLE SALES LOCATIONS
id location_name customer_id ... other fields
2 normalville 4
where customer id is the primary key in another table:
TABLE CUSTOMER
id name industry
4 EXC Selling Things
is there any elegant way to accomplish this with SQL without using a whole slew of joins or subqueries specifically targeted at each of the 50+ fields?
there are probably 11 fields in the main table that are actually just ids pointing to other tables.
also of note, I am using the Yii framework.
Thanks!
This is a subject that has been discussed multiple times and it always depens on the situation, but I like to share my idea.
Im building a new CMS that must support multilingual applications and can be installed behind existing applications.
The solutions I know and found are:
[Product]
id
price
name_en
name_de
name_fr
only getting the fields you need in your language.
or using mutliple tables like:
[product]
id
price
[languages]
id
tag
[product_translation]
product_id
language_id
name
Joining the correct language
Both situations work and have its pro's and cons. Based on your choice you have to rewrite your query's.
my idea:
[product]
id
price
name
[product_translations]
product_id
language_id
name
[product_es_view]
id -- references the product table
price -- references the product table
name -- references the translation table
Now the idea is that you create a view for every language, but the view is identical to the product table.
Why?
With this setup I can make non-multilingual sites, multilingual without editing the existing model/table. Now the only thing I have to do in my code is use another table and i get a translated version of my model (in php it could be done by adding a simple trait to your model). With SQL server and Mysql you can use updateable views which save the value's in the referenced tables.
I love to hear what you guys think of the idea, and most of all what the biggest cons are of using views for this problem ?
I prefer the second option where every entity is in its own table. If you use product_es_view then it may be easier but less clean code.
Adding new languages should usually not include adding new database tables. Adding new row to languages tables is better.
I am doing a database for a project and im stuck in a point.
Since every product can have multiple field of use, but even every materials can have multiple field of use, i come up with that solution.
THis is my database architecture.
http://i57.tinypic.com/2mhc03o.jpg
product are specifical for every material e.g. there can't be the same product for 2 material
material are leather, simil-leather, cloth, PVC
field of use are the field which that material can be used: sport, leisure, work
The problem is that material can be used in many field and many field can be used for a material, so it's N:M
Every product can be used in many field and many field can be used for a product so it's too N:M
For example, leather can be used in work, sport, cloth in work sport and office
product can be used in some or all field of application and vice versa.
1)WIth my architecture, to retrieve a material that can be used in a specific field of use i need to do 4 JOIN between all the table. Is it ok? or it's too long?
2)Also, when the user want to add a new category, to insert which field of use that category can have, i need to have a product already for that category.
3)when i want to fill a many to many relationship, i need to do it manually in the conjuction table (field_of_use_product) with some php codes right?
You need three joins for four tables that involved.
No, product may insert after all of the data at foreign tables have inserted.
Yes, it's a simple insert if you know the foreign keys.
I am working on an online jewelry store website. One of the requests is that from the back end a color/colors can be chosen for a single piece of jewelry so that users would be able to sort/view only items that are for instance green.
What is the best way to store this in a database? Should this be done with 3 tables:
product table (already exists)
color table : each field has a color
table that matches the product is with the color id
Is this the correct way to do it? I am using php and mysql but I think this is just a pretty standard database question.
Yes, your solution with a many-to-many relationship between tables sounds good for your case. You can then easily JOIN the tables to get information out of the IDs.
Yes, that's an appropriate way to do it.