I am making ERD for Wine warehouse. I have one question about the table
so if i have products table and there are different kinds of products like red wine, white wine and rose wine. can i make table to products and then make tables of each wine and link those tables to product table?
thanks
Your question is one of database design... yes, you could arrange tables as designed... The question better asked however, is SHOULD you design your database that way. Creating separate tables for each category of product absolutely can be done... the issue is that in order to run any kind of query/report against products in general means you have to solve the problem of including data from multiple tables...
You could create a database view, which is essentially a massive JOIN query... to keep that efficient however you want to be sure to design all of those separate tables nearly identically...
Another alternative would be to consider table inheritance... if the database management system your software is utilizing supports it... essentially your product table would be a parent of all the different product tables... the columns on that table would be inherited by all the child tables... making reporting at the product table level for ALL products a bit easier... You do need a separate list of reports then at the product specific table level then to include columns specific to each of those tables.
So... the answer is YES, you can do as described... the REAL question is SHOULD you.. and the answer to that as I hopefully have illustrated is well beyond the scope of the information you provided in your question. There are MANY factors that will play into how you should organize the data in your database for efficient use.
Related
:)
I recently started working with aws platform, and i'm having a hard time developing one thing.
Basically i want to link two different dynamodb tables( like company table and orders table), and one company can have different orders connected to it. The first thing i have done was store in company's table a list of orders id, but the problem is that i cannot index an array, so it is kinda problematic to know the orders in that company, because it cant be done pagination.
I cannot figure out a better solution, so if any of u more experience developers can indicate me a way to store this association, i would be very grateful.
Thanks
Quick Summary: I'm building an ERD diagram and got lost in connecting two tables.
Introduction:
I'm building an ERD diagram for my project. Idea is pretty straight forward: I can type information about the company and it will be saved in the database. Later, I can see the list of submitted companies, as a list. As of now, I've information on the "paper", which I've implemented into my ERD diagram, so that later I can tell database, what exactly must be saved and where.
I have a primary table "Company_Info" which stores all the information about the company in the database. Using common sense (or not :)) I've created "Foreign Tables" that would store information about the company: "Gallery Images", "Opening_hours", etc. This way I believe, the database would more or less clear and readable by others.
ERD Diagram with the Description of all relationships
Problem Statement
The idea was to create a simple gallery for the company, so that they can upload their Product-pictures. If it's possible I would like to talk about the relationship between the Gallery and the Company tables. The way I see it, I think it should be like this:
One company can have 0,1,2 or many images. (Gallery_Images Table)
Images must be assigned to only 1 company. (Company_Info Table)
The relationship is one mandatory to many optional. (Many images & one company)
Question: I think the relationship between the Gallery_Table and Company_Info table will not work. Reason: Wrong relationship. I'm confused about the connection between those two tables.
I have made a connection via company PK & FK. This way, I think, the database would know what images belong to that specific company.
Confusion is with gallery_id in Gallery_Images table. Shouldn't it be connected with the company_info table too?
Image(BLOB) is a repeating group in Gallery_Images. This is not a problem if your purpose is to draw a diagram of an ER model.
If your purpose is to draw a diagram of a relational model, then the repeating group is a departure from First Normal Form. Relational schemas that depart from 1NF are generally subject to terrible problems, both with regard to performance and with regard to data management itself.
I don't see the Gallery table in your diagram. Did I miss something?
Sorry if this question have been asked but i couldn't find clear answer on this subject.
I'm having troubles while creating my elasticsearch index, i'm not really sure how to manage relations properly.
Let's say i have we have the following entities:
Product
id
reference
Book
id
name
product_id
Shirt
id
color
product_id
StockItem
id
supplier_id
product_id
quantity
I'd like to :
Find a shirt from it's color
Find all books given by supplier_id 5
I wasn't able to find if i was supposed to do multiple queries, nested objects, parent/children relations, etc... I couldn't find a proper tutorial which says "do it that way".
Actually i'm working with nested objects but i find it quite dirty to redefine, in each of my type, all the data i need.
Do you have some advice on this ?
Thank's.
The key to searching and modeling relationships in Elasticsearch is to denormalize. This is because Lucene has a flat data model with no built-in support for relationships in your data.
Think of it from the perspective of your search results. What is the thing being searched for? What shows up in your search results? That is the thing you are searching against. If you want to filter or sort those things based on the values in a related object, then you need to pull those values in at indexing time.
If you're searching for shirts and want to filter by color, then your shirt documents should all have a color field on them. If you are searching books and want to filter to a certain supplier, then you should include the supplier name or ID as a field on your book documents.
Your choice of language and ES client may make this easier. For example, in Ruby, you can index the results of arbitrary method calls, allowing you to dynamically fetch from other associated models while indexing your data.
Nested structures or parent child relation is your best bet. I hope this blog will help.
I have a question about queries optimization and data "grouping"
Here's my setup :
I have a single application for multiple sites
Items I display to my sites are stored in a single table (one item can be shown in different sites)
So I have joins between my "sites" table and "items" table
When a user authenticate in site01 i'd like to present him only the data for this site.
I was wondering if there was a genius doctrine (or other) trick to make it transparent in my code:
For example:
User authenticates for site01
I set in my siteManager that it's 01
And all my entities of items (for this session) now refer to a subset of my data according to the JOIN with site01.
Like a view or something.
My concern is as much performance optimization than transparency in code.
Performance coming first.
nb: the choice of using a single item table is not definite yet, it might be a bit to meta and/or conceptual to provide good performance.
Thank you in advance for any input on my question.
Am making a cube in SQL Server Analysis Services 2005 and have a question about many to many relationships.
I have a many to many relationship between two entities that contains an additional descriptive column as part of the relationship.
I understand that I may need to a bridge table to model the relationship but I am not sure where to store the additional column - in the bridge table or elsewhere?
Many To Many relationsip in SSAS can be implemented via an intermediate fact table that contains both dimension key that subject to the relation.
For example; If you have a cube that has a book-sales-fact table and you want to aggregate total sales by author (which may have many books and a book may be written by many authors) you should also have a author-book intermediate fact table (just like in relational database world). In this bridge table, you should have both dimension keys (Author and Book) plus some measure related to the current book and author such as wages paid to the author to write the book (or chapters).
As a result, if your additional column is kind of a measure you should add that column to the intermediate fact table.