I have to build a database with clients and products. The problem is that i should have two types of clients: individuals and companies. I don't get the philosophy for starting the project and some guidelines would be great!
How can i construct the database or the queries to link products to a specific type of client?
Should i make a third clients table and link individuals and companies tables to this table and the products table also linked to this third table or should i have 2 tables for individuals and companies and a flag inside both like "is individual" and "is company"?
When i generate the form to enter a new client i should first select the type of client and based on that a specific form for individuals or company should appear.
Is it a better way to construct that type of client-products database? If i kinda join the two types of clients into just 1 table (an individual have approximatly the same characteristic as a company) it's easy.
Thank you very much!
Related
Need your help or suggestions over my case here in SSAS modeling
I am basically struggling with 4 tables, Customer, CustomerPhone, CustomerEmail, CustomerBusinesses.
Providing the sample data below, only the dimension Customer is linked to all, because Customer has one values.
The other tables will have a scenarios like a customer can have multiple emails, phone and can be a customer of mutiple businesses.
I cannot maintain all these into one custome dimension, because my fact is referring based on Global Customer ID, if I join the Global Customer ID's will duplicate
My reporting end is Power BI, and my intent is by selecting a Customer Name on filter and it show show me multiple phone, emails and for which all business he is been.
I tried using a reference Relationship, but it is not working, though it work, it has to queries against a measure group.
Would there be any way to achive this.
Let me know if any additional info is required here.
Thanks
I have a database I'm working on the design for. I have manufacturers and I have distributors on separate tables containing practically the same information with few exceptions. Both groups have one-many contacts that need to be connected to them. I created a contact table to hold contact information, one!
Do I need a second contact table? I'm trying to make this as DRY as possible. How would that look? Thank you in advance
Maybe a case for the party-role pattern? Manufacturer and Distributor are roles played by Parties. Contacts apply to Parties, not the role(s) they play. So you'd have:
a table named Party
a table named ContactMethod (or similar)
a 1:M relationship from Party to ContactMethod
which would resolve the need for two Contact tables. How you model the roles side will depend on wider requirements. The canonical model would have:
a single supertype named Role
a M:M relationship from Party to Role
a subtype of Role for each specific role (Distributor and Manufacturer in your case).
(Note: as an aside, this also allows a Party to play both manufacturer and distributor roles - which may or may not be relevant).
There are 3 'standard' patterns for implementing a subtype hierarchy in relational tables:
table for entire hierarchy
table per leaf subtype
table per type
(1) would apply if you don't have any role-specific relationships. (However I suspect that's unlikely; there's probably information related to Distributors that doesn't apply to Manufacturers and vice-versa).
(2) means multiple relationships from Party (i.e. one to each role subtype).
(3) avoids both above but means an extra join in navigating from Party to its role(s).
Like I say, choice depends on wider reqs.
hth.
first of all sorry for my bad english hehehe I need some help, I want to design a database for a website, like a mini Amazon. This database will manage every kind of products (TV, cars, computers, books, videogames, penciles, tables, pants...), but also, each product must have some properties (that will be indexed) for example, if the product is a book, the properties will be something like genre, year, author. If the product is a TV, the properties will be something like size, color, also year. And if the product is a car, the properties will be something like year, color, model, for example. So, this is my idea:
One table to manage departments (like electronics, books...)
One table to manage categories of the departments, this table will be a child of the previous. If the department is electronics, here will be audio, tv and video, games... (each category belongs to one department, the relationship is one department to many categories)
One table to manage the products (each product belongs to one category, the relationship is one category to many products)
One table to manage properties (like year, color, genre, model...)
One table to engage products with properties, this table will be called ProductProperties
Im not sure if this is the best way, the database will be huge, I will develop the database on MySQL. But, I think this is not the best way, this article talks about "Database Abstraction: Aggregation and Generalization" http://cs-exhibitions.uni-klu.ac.at/index.php?id=433, in other words generic objects (I think), but this way is old (70s). In this article http://www.simple-talk.com/sql/database-administration/ten-common-database-design-mistakes/ in the section "One table to hold all domain values" says that this is a wrong way... Im saying all of this because of the table ProductProperties, I dont know if I make this table or if I make especific tables for each kind of products.
Do you have any suggestion? Or do you have a better idea?
Thanks in advance, take care!!!
1.One table to manage departments (like electronics, books...)
2.One table to manage categories of the departments, this table will be a
child of the previous. If the
department is electronics, here will
be audio, tv and video, games... (each
category belongs to one department,
the relationship is one department to
many categories)
Why? One table, categories, forming a hierarchy. More flexible.
3.One table to manage the products (each product belongs to one category,
the relationship is one category to
many products)
Why? Allow m:n here. A product in many categorries.
Im not sure if this is the best way,
the database will be huge
Ah - no. Sorry. Nontrivial, yes. Hugh? No. Just to get you an idea of hugh - I have a db I am adding 1.2 billion rows PER DAY to a specific table. On average. THIS is big. YOu end up with what - 100.000 items? not even worth mentioning.
Pablo89, the description of what you want is very close to what the AdventureWorks database for SQL Server does. There are many examples of using AdventureWorks on the Web from web applicatons to reporting to BI.
Download and install SQL Server Express 2008 R2. Download and install the sample database for the above product. Inspect the database design for AdventureWorks.
Use AdventureWorks as examples in questions you may post.
I use AdventureWorks because I use SQL Server. I do not say it is better than other database products I say this because I know AdventureWorks.
I do not think that some database can work fast with 500,000,000 items. Complete tree of products categories for amazon.com contains 51,000 nodes (amazoncategories.info). Also the data is updated hourly, so saved product information can be incorrect. I think the optimal way is to store categories tree only get the product data at runtime using Amazon's API.
I'm having trouble setting up a report model to create reports with report builder. I guess I'm doing something wrong when configuring the report model, but it might also due to change of primary entity in report builder.
I have 3 tables: Client, Address and Product. The Client has PK ClientNumber. The Address and Product both have a FK relation on ClientNumber. The relation between Client and Address is 1-to-many and also between Client and Product:
Product-(many:1)-Client-(1:many)-Address.
I've created a report model (mostly auto generate) with these 3 tables, for each table I've made an Entity.
Now on the Client Entity , I've got 2 roles, Address and Product. They both have a cardinality of 'OptionalMany', because Client can have multiple Addresses or Products. On both Address and Product I have a Client Role with cardinality 'One', because for each Address or Product, there has to be a Client (tried OptionalOne as well...).
Now I'm trying to create a report in Report Builder (2.0) where I select fields from these three entities. I'd like an overview of Clients with their main address and their products, but I don't seem to be able to create a report with fields from both Address and Products in it. I start by selecting attributes from Client, and as soon as I add Product for example the Primary entity changes as if I'm selecting Products (instead of Clients).
This is a basic example of a problem I'm facing in a much more complex model. I've tried lots of different things for 2 days, but I can't get it to work. Does anyone have an idea how to cope with this?
(Using SSRS 2008)
Edit: in T-SQL this is what i mean:
SELECT *
FROM CLIENT
INNER JOIN ADDRESS ON CLIENT.CLIENT_NUMBER = ADDRESS.CLIENT_NUMBER AND ADDRESS.TYPE = 1 --Main Address
INNER JOIN PRODUCT ON CLIENT.CLIENT_NUMBER = PRODUCT.CLIENT_NUMBER
WHERE CLIENT.CLIENT_NUMBER = 1
My experience dates back to Report Builder 1.0, but MS hasn't changed much in their report model since so it probably still applies.
As you mention, you can define many to many relations in the model, but materializing those relations in one tabular report is not possible. Once you chose one of the entities on the many side (Products), you are left without a way to bring data from the other side (Addresses).
You may have some luck with creating a "junction" table (ClientID-AddressID-ProductID) and hidding it from your users like Bob's SQL Reporting Services Blog suggests.
Ultimately this is a big limitation with MS models and it doesn't seem to improve with their latest incarnation Denali BISM many-to-many
I understand the original post is 4 years old and SSRS report models are becoming irrelevant but one solution is to define the OptionalMany relationships as OptionalOne in the model, essentially fooling the model to allow navigation and appropriate query generation.
I am trying to work out the best database model for the current setup:
An administrator can create "customer products". This means services/products which customer can attach/subscribe to. The simple cases where the product simply costs a price, or the product subscription should send an e-mail is easy to model in the database.
But how about very specific backend code for a customer product? For example, one product might have very specific code implemented for checking a customer status on a different database. How can I map this relationship in the database so I can turn on/turn off some code based on the product settings.
My intuitive way of handling it would be to have a string column on the CustomerProducts table where a pre-defined set of strings could be set, e.g. "MyCustomCodeHandler", and then the code would check for the existence of this string in order to execute it. But for me it doesn't really feel like a real relationship between the database and code.
Data is data, whereas code is code. I would not recommend storing code in the database.
If you need to allow customers to create product types (in the object-oriented sense of "types") with associated code, I'd choose to deploy that code in the same way you deploy other code.
The custom code may also reference custom data stored in the database. I'd choose to create a dependent table per product subtype, and put the type-specific columns in there. The relationship between this subtype table and the generic product table is one-to-one. That is, the primary key in the subtype table is also a foreign key to the generic product table.