Hello we are now working on international site design ,so many table need to have relation to the same shaped small translation table , which store translation for each langueges like left side of the image (Design#1).
Currently we have an idea to merge translation table like right side of the image (Design#2), but I'm not clear this design is good or bad. Could you tell me Design#2 is good or bad idea ?
Also if you have another solution for this case , please give me an advice.
Related
I'm a university student who is completely new to SQL and I don't know what I'm doing, so go easy on me. I have been given an assignment to design a Facebook-like database for a website for people who read books. I have made a very basic data dictionary which gives the general idea.
Is this a valid approach? Is there a better way of doing this? I'd appreciate any feedback I can get.
First of all, I would say good to see your efforts.
Here I would suggests you bit enhancements. Instead of maintaining different tables for
books_liked,books_read,wish_list, etc., you can maintain same with the help of flags in the master table books. This is to normalize your data.
eg. flg_liked, flg_wish_list, flg_read
I want to create a database that has the table for sales and services for a certain company. What I want to know (since I don't know much of SQL) if there a way to store like an object that represents a list or array in a single cell. Why? Because I want a cell in the Sales table to point to all the services that generated that particular sale. For example:
A sale of in 09/09/11 that was generated by service_1, service_2, ... , service_n . Where service_# is a certain service that this particular company offers. Again I apologize for my stupidity but I'm now in the process of learning SQL.
I'm planning to create the database on SQL server.
This is a bad approach.
Database must be well normalized. You are talking to make a design that is not in first normal form.
That you are loking for is a N:M relation ship, you should create a new table called sale_services:
sales (saleId, ...)
services (servideId, name, price, ...)
sale_services( saleId, serviceId)
As a rule of thumb, as soon as you want to add multiple things in one cell, change your database design. Split the tables. Use one table called Sales, another called Services and then a last one that joins the two together which has the ids of the sales and services you want to "join".
As others have said, just wanting to store an array is a sign that you are designing incorrectly. If you want an array of data, what you really need is a related table to store that information in individual records.
What I want to talk about is what happens when you decide to store an array in a field, separated by a comma for instance.
Suppose you store the available colors of a product in a field called colors.
Now you have
Product Colors
item1 red, blue, yellow
item2 blue, purple, red
and so forth for a million records
Now how do you find all the products that come in red? Array fields are difficult to properly query and the performance when you do so is generally abysmal. Adding a new color is also a pain point especially if you want it to be in a certain order.
Before you go any farther in designing a database you need to read about normalization and database design. One of the very first rules of database design is NEVER store more than one piece of information in a field in a record. This is a complex subject and making the wrong choice early on can kill your system. Database are not simple or easy to refactor so you need to know what you are doing at the time you create the design.
Lots of good comments here.
You might want to take a step back and look at the bigger picture of your database. The comments here are from practical experience, not just text books. Try to see what other uses will happen with your data. In your example, if you stored the service list in a single cell, like you mentioned, how would you determine which service was performed the most? How about what services are never used? If your solution requires reading every "row" and doing something, than most likely there is a better approach.
If you put together a suggested design, many people here will help you tweak it and fine-tune it to make it better..
Good luck...
Is it a good idea to create a schema type to separate the table relationships. I guess when you are browsing the tables in SSMS you will see them group together by schema type. But is it worth the trouble? Anyone with experience with this in real world scenarios?
I've generally found that to be more of a hassle than any help it's provided. What do you do with tables that are relevant to multiple areas? What happens when a table seems to belong to one area but later migrates to another area of the application? Do you change its schema and refactor all of your code?
I have used multiple schemata to make delineations when there is a VERY clear boundary between objects, but usually not something like what you have in your diagram. One example is objects which are used just for DBA support. I might put those into their own schema if they aren't used by the actual application itself.
I am building an application in which i am getting data from xml and data can grow dynamic,i am displaying location name on first view, and each location have multisubviews and sub views have multi hotels name, hotel image and hotel description and each hotel has further photo gallery, so at this condition i am facing problem how to store data on array i mean what will be smart logic to handle this and arrays should use as minimus as possible, Someone can help me???
Core Data has a good size learning curve, but a lot of boiler plate code is provided for you and the Apple documentation is pretty good. It's definitely worth learning, especially for things like this. For a starter, so you will understand it in perspective, your hotel will be your entity.
Basically, the below image represents the components on the homepage of a site I'm working on, which will have news components all over the place. The sql snippets envision how I think they should work, I would really appreciate some business logic advice from people who've worked with news sites before though. Here's how I envision it:
Question #1: Does the sql logic make sense? Are there any caveats/flaws that you can see?
My schema would be something like:
articles:
article_id int unsigned not null primary key,
article_permalink varchar(100),
article_name varchar(100),
article_snippet text,
article_full text
article_type tinyint(3) default 1
I would store all articles ( main featured, sub-featured, the rest ) in one table, I would categorize them by a type column, which would correspond to a number in my news_types table ( for the example I used literal text as it's easier to understand ).
Question #1.1: Is it alright to rely on one table for different types of articles?
A news article can have 3 image types:
1x original image size, which would show up only on the article's permalink page
1x main featured image, which would show up on the homepage section #1
1x sub featured image, which would show up in the homepage section #2
For now I want each article to correspond to one image and not multiple. A user can post images for the article in the article_full TEXT column though.
Question #1.2: I'm not sure how I should incorporate the article images into my schema, is it common for a schema that relies on 2 tables like this?
article_image_links:
article_id article_image_id
1 1
article_images:
article_image_id article_image_url
1 media.site.com/articles/blah.jpg
Requirements for the data:
From the way I have my sql logic, there has to be some data in order for stuff to show up..
there has to be at least one main type article
there has to be at least four featured type articles which are below the main one
Question #1.3: Should I bother creating special cases for if data is missing? For example, if there's no main featured article, should I select the latest featured, or should I make it a requirement that someone always specify a main article?
Question #1.4: In the admin, when a user goes to post, by default I'll have a dropdown which specifies the article type, normal will be pre-selected and it will have the option for main and featured. So if a user at one point decides to change the article type, he/she can do that.
Question #1.5: The way my featured and main articles work is only by the latest date. If the user wants, for example, to specify an older article for whatever reason as the main article, should I create custom logic, or just tell them to update the article date so it's later than the latest?
In regard to the question in the title there is definitely more than one way to skin a cat. What's right for one site may not be right for another. Some things that could factor into your decision are how large the site needs to be scaled (eg are there going to be dozens of articles or millions?) and who will be entering the data (eg how much idiot-proofness do you need to build in). I'll try to answer the questions as best I can based on the information you gave.
Question # 1: Yes, looks fine to me. Be sure to set your indexes (I'd put indexes on [type,date] and [category,type,date]).
Question #1.1: Yes, I would say that is alright, in fact, I would say it is preferred. If I understand the question correctly (that this is as opposed to a table for each "type") then this sets you up better for adding new types in the future if you want to.
Question #1.2: If you only want one image for each story and one story for each image I'm not seeing the advantage of splitting that up into an extra table. It seems like it's just more overhead. But I could be missing something here.
Question #1.3: That's a design decision up to you, there's no "right" answer here. It all depends on your intended uses of the system.