How would I go about defining a table with a language specific (qualified) attribute?
For example:
ID| object |description (english)|description (french)| size | color (english) | color (french)
in the above example we have 3 'normal' fields and 2 language qualified fields : description and color.
What is best practice for defining these type of fields within one table?
There are different ways of doing this. But a method for your specific data is to have another table with one row per language. Such as table would have:
objectLanguageId (serial column to identify the row)
objectId (reference to a table with one row per object)
language
description
color
Then the "object" table would have
objectId
objectName
size
Note: This is definitely not the only approach. If you need everything in your system translated, then you want a more sophisticated and generic mechanism. You may also need to take into account things like French sizes are different from sizes in other countries -- even countries that speak the same language.
Related
I have four levels for categorizing items according to their attributes. Some items may not require all subcategory levels and some items may share the same subcategory values.
Examples:
Category1 Category2 Category3 Category4
--------- --------- --------- ---------
Jewelry Ring Wedding
Jewelry Bracelet Serpentine
Jewelry Necklace Serpentine
Equipment Tool Power Drill
Equipment Tool Hand Jigsaw
Accessory Battery AA
Accessory Movie DVD Action
Accessory Game PS3 Combat
I want the lookup tables to contain values which are related to each item so that when users select a value from the dropdown list in the first category, the corresponding values in the next subcategory will automatically drop down (cascade), and so on.
I will predefine non-deletable, non-updatable values for most common items, however I cannot provide all possible items, for which I want to allow users to add values from the second level on down.
The objective for classifying each item is to provide a uniform method for describing items and for queries to effectively return all desired items.
Questions:
How can I make sure that new values which are added by users will link properly to parent or child values?
Should I allow users to add new categories and subcategories or should I force them to only select from pre-defined values, chose 'Other' value if their item does not fit into one of the pre-defined and enter a free-form comment?
Is the current method I have defined the best way or do you have a better suggestion?
Below are the current tables and relationships I have defined:
Columns MS-Access Informix Comments
-------------- ------------ -------- ----------------------------------------
Primary keys Autonumber SERIAL
Foreign keys Long Integer INTEGER
English Text VARCHAR Description in English language.
Spanish Text VARCHAR Description in Spanish language.
NonDelete Yes/No CHAR(1) Cant delete predefined value if TRUE.
NonUpdate Yes/No CHAR(1) Cant update predefined value if TRUE.
Deleted Yes/No CHAR(1) User-defined value cant be used anymore.
StockKeptUnit Yes/No CHAR(1) Non-serialized inventory item if TRUE.
Don't they properly link by definition? That is sort of the point of the PK/FK relationship, after all.
Presumably creation of a new tlkpItemCat2 involves selecting a valid parent tlkpItemCat1, or the INSERT would fail. As long as tlkpItemCat2.ItemCat1_SIID is defined as NOT NULL, you're pretty much assured of a valid relationship.
That doesn't guarantee that the end-user hasn't declared that a Necktie is a Power Tool, but that's a whole different problem.
Now, from experience with this exact issue (object categorisation), I can tell you that although this design looks quite elegant and useful, it is awful from a usability perspective. Your user has to know the hierarchy in advance to quickly locate the correct category for an item. And once end-users start adding levels to your hierarchy, it becomes a nightmare of back-and-forth, dead-end searches trying to locate the correct combination of Cat1/Cat2/Cat3 to apply - which leads to anything-will-do-just-to-get-past-this-screen categorisation.
A better approach is to allow the user to simply type in 'Jigsaw', and return a list along the lines:
Did you mean:
[] Equipment | Tool | Power | Jigsaw
[] Equipment | Tool | Hand | Jigsaw
[] Game | Childrens | Jigsaw
[] Accessory | DVD-Movie | Horror | Jigsaw
[] ... or [something else]?
Yes, it's more work, but from a UI and UX perspective, worthwhile.
This should allow for infinite categories. You'll need to enforce non-orphaning through your UI or OnChange events.
Then your table content would look like this:
As part of addresses I am storing in my SQL database country codes (e.g. US, DE,...). I then have another table (with two columns) in my database which translates the country codes to the English language names of the respective countries.
If I want to make the site multi-language, I could expand this translation table adding country names in other languages than English.
I was wondering if there is another method which does not involve modification of the database, e.g. using gettext to translate the English country names?
The typical way to handle this is to change the table structure to have three columns, instead of two:
Language
CounryCode
FullName
Whenever you query the database, you would provide the current language.
You then have to change your code to include the additional language key in any queries.
Depending on how you are going to keep track of the current language, you would also use a view or user defined function.
You don't want to use automated translation, since the name of a country like "China" could turn into the equivalent of "porcelain".
I am interested in the implementation of the search engine in autoscout24.de. It is a platform where you can sell/buy cars. Every car advert has properties: make, price, kilometers, color, etc. (in sum over 50 different properties) that can be searched for.
I am specifically interested in the detail search that works like this: every possible property is displayed on the page. In brackets behind each property there is the number of cars that will match the new search if the property is selected.
Example: I'll start with empty search criterias.
Property make:
BMW (100.000)
Volkswagen (200.000)
Ford (150.000)
...
Property color:
black (210.000)
silver (50.000)
white (100.000)
...
and so on for the other properties.
I'd like to know:
How would you implement this kind of search with SQL?
How would you implement it with an in-memory data structure?
Range queries should be supported, too (all cars with price from X to Y)
Update:
The numbers in brackets show the number of results after the addition of the search criteria. So it changes each time a property is added / removed...
So a naive algorithm would work like this:
find all cars with current search criteria (e.g. make Ford)
for each property do: find all cars that matches previous search criteria ("Ford") AND the search criteria for the chosen property. Write the count in brackets behind the property.
This algorithm is naive because it would execute 1 + N queries (N=#properties). Nobody wants to do that ;-)
I believe that this is referred to as "faceted search". The Apache Solr project might be worth looking at.
It's a basic code
Create a result object with one counter for each property that the cars have
Check all cars one by one, if the car match the filter then add one to each of the numbers
...But it's blasting fast !
I think they do it on several computers, shreading data across them. Each computer compute 5% of the data and send the result to the front computer wich sum all counts.
There are tools for that : look for "map reduce", "elastic search", "strom"...
Have a properties table:
+Properties
id
title
value
count
The count field allows you to "earn" an extra query , so instead of checking how much cars have a certain property , you can just update this field when adding new cars.
Example of rows in this table:
1 'color' 'white' 1000
2 'color' 'black' 122
3 'km' '5000' 1233
4 'km' '30000' 54
And for the cars table , for each property add a field.
+Cars
id
color
km
and the color and km fields will hold the ID's of the property's row in the Properies table.
EDIT: if you're planning not to use mysql db , you might consider using XML files to contain the properties data. But once again, you should update its count value anytime you add / remove or update a car.
<Properties>
<Property>
<Type>Color</Type>
<Value>White</Value>
<Count>1000</Count>
</Property>
</Properties>
Here is my dilemma, I am building a POS system for a pretty large retailer, they have different products which have different attributes (size, color, etc...).
When they receive the merchandise from the supplier they want to do their own labeling with their own UPC Bar Codes but they also want to differentiate between the different sizes using the code on the article.
Say they received Brand A shirts with 4 sizes S,M,L,XL then they should have different bar codes for each size.
So I thought of having a base code for the article and then concatenating numbers depending on the attributes to have different codes? and if no attributes are available just add 0s
I am storing the sizes and colors as attributes in the database as an (Entity-Attribute-Value). Is their a better way other than having to start concatenating numbers from the attributes to come up with the full code?
Thanks for your help!
edit-------------------------------------------------------
I am making the example a bit clearer
so the base code for the shirts is: 9 123456
Then for Color blue is: 789
and then for size S: 012
so the full code is 9 123456 789012
for another article that doesn't have size or color or actually any attribute
the base code would be 9 654321
plus 000000 for the attributes part
this is just for simplicity sake as I can use only one digit per attribute.
The other issue is when linking to the OrderDetails table I need to reference all the attributes to know that the customer actually bought Size S in Blue
One possible option is to create a table that stores the bar code as the key. Then have an attribute for the size and the color.
Actually #jzd your answer is pretty close but I would like to keep the attributes as key value pair.
The idea is to use and an attribute set and have a bar code associated with each set. here is a rough schema
AttributeSet Table:
AttributeSetId
ProductId
AttributeSetName
BarCode
AttributeUse Table:
AttributeSetId
AttributeId
AttributeSetInstance Table:
AttributeSetId
AttributeId
AttributeValueId
if you forget the barcode for a minute...
do you have a database to track this inventory?
are the items stored discretely in this database?
if so, then just add a unique number to the item, called the UPC vale - i recommend not trying to make an intelligent key s\as you are describing
I'm developing a website with a custom search function and I want to collect statistics on what the users search for.
It is not a full text search of the website content, but rather a search for companies with search modes like:
by company name
by area code
by provided services
...
How to design the database for storing statistics about the searches?
What information is most relevant and how should I query for them?
Well, it's dependent on how the different search modes work, but generally I would say that a table with 3 columns would work:
SearchType SearchValue Count
Whenever someone does a search, say they search for "Company Name: Initech", first query to see if there are any rows in the table with SearchType = "Company Name" (or whatever enum/id value you've given this search type) and SearchValue = "Initech". If there is already a row for this, UPDATE the row by incrementing the Count column. If there is not already a row for this search, insert a new one with a Count of 1.
By doing this, you'll have a fair amount of flexibility for querying it later. You can figure out what the most popular searches for each type are:
... ORDER BY Count DESC WHERE SearchType = 'Some Search Type'
You can figure out the most popular search types:
... GROUP BY SearchType ORDER BY SUM(Count) DESC
Etc.
This is a pretty general question but here's what I would do:
Option 1
If you want to strictly separate all three search types, then create a table for each. For company name, you could simply store the CompanyID (assuming your website is maintaining a list of companies) and a search count. For area code, store the area code and a search count. If the area code doesn't exist, insert it. Provided services is most dependent on your setup. The most general way would be to store key words and a search count, again inserting if not already there.
Optionally, you could store search date information as well. As an example, you'd have a table with Provided Services Keyword and a unique ID. You'd have another table with an FK to that ID and a SearchDate. That way you could make sense of the data over time while minimizing storage.
Option 2
Treat all searches the same. One table with a Keyword column and a count column, incorporating SearchDate if needed.
You may want to check this:
http://www.microsoft.com/sqlserver/2005/en/us/express-starter-schemas.aspx