I´m starting in database schema. I don´t have experience in it.
I am thinking of a platform for customers to have access to the types of products that suppliers offer.
So, I would like to know how to keep the database schema following the tables and their relationships.
The customer will be registered in the system and he will have access to suppliers and their products.
Costumer>>>>>>>>>Product>>>>>>>>>Supplier
I already thank anyone who can help.
greetings
Ed
Based on the data you've given.
You would have a Product table, a product can be sold by one or more supplier. So you would have a Supplier table. Since this is a many to many relationship you would have a cross reference table
Customer's wouldn't be related to Products or suppliers.
Customers generally don't have a direct relationship with Products. Generally, customers create orders, composed of multiple products.
So customers typically have a one to many relationship with an 'Orders' table. The Orders table has a one to many relationship with an OrderItems table. That table might store quantity, color, etc, and has a many to many relationship with the Products table.
Of course, that's just the typical entity relationship. Without more information, it's hard to know if it meets your needs or not.
Related
First of all I have to mention that I am modernising our ERP system that is build in-house. It handles everything from purchasing of parts, sale orders, quotes and inventory to invoicing and statistical data. The system is web based and heavily dependent on ORM. EloquentORM will be used in the redesign.
My main question is about the data model of certain entities that are very similar. Currently three of most widely interconnected entities in the app are: Orders, Products and Invoices.
1. Orders
In current DB design I have one big orders table in which there is a order_type attribute to distinct between different order types: Purchase orders, Sale orders, Quotes and Service orders. About 80% of fields are common to each order type and there are some specific fields for each order types. Currently at ~15k records.
2. Products
Similarly I have one big products table with an attribute product_type to distinct between different product types: Finished products, Services, Assemblies and Parts. Again there is a fair % of fields that are common throughout all product types and some that are specific to different product type Currently at ~7k records.
3. Invoices
Again one table invoices with invoice_type attribute to distinct between 4 invoice types: Issued invoices (for things we sell), Received invoices (for things we buy), Credit notes and Avans Invoices. More or less all invoice types use the same fields. Currently at ~15k records.
I am now trying to decide which is the optimal way for this kind of DB model. I see three options:
1. Single Table Inheritance
Leave as is, everything in the same table. It feels kind of awkward to always filter records like where order_type = 'Sale order' to display right orders in the right place in GUI... Also when doing sale and purchase analytics I need to include the same where condition to fetch right orders. Seems wrong!
2. Class Table Inheritance
Have a master tables orders, products and invoices with common set of fields between each of entity types and then one-to-one child relation tables for every different type of each entity: sales_orders, purchase_orders, quote_orders, finished_products, reseller_products, part_products, assembly_products, received_invoices and issued_invoices with FK in each of the child tables to master table... This seems like a good idea but handling that with ORM brings in a little more complexity...
In this method I have a questions which FK should be used around. For example each invoice can belong to one order. Received invoice will go with Purchase order and issued invoice will go with Sale order. Should the master orders table's PK be used as a FK in the master invoices table to relate these entities, or should the child sale_orders PK be used in the child issued_invoices?
3. Concrete Table Inheritance
Having completely separated tables for every type of each entity. This would avoid me having parent->child relationship between master table but would result in a lot of similar attributes in each table...
What would be the best approach? I am aiming at ease of use in EloquentORM and also speed and scalability for the future.
I've run into a bit of a pickle during my development of a web application. I've boiled down the complexity of the application for sake of simplicity in this question.
The purpose of this web application is to sell insurance. Insurance can be purchased through an agent (Agency) or over the phone directly (Customer). Insurance policies can be paid through the agency or the customer can pay for the policy directly. So money is owed (invoiced) and received (payments) from multiple sources (Agencies/Customers).
Billing Options:
Agency (Agency collects from customer outside of app)
Customer
Here's where it gets complicated. Agencies are stored in a separate database table than customers (for obvious reasons). However, both agencies and customers need to be able to make payments and have invoices assigned to them. I'm having difficulty figuring out how to create the proper database schema to allow for both types of database records to be connected to their invoices and payments.
My initial plan was to set up separate relationship (joining) tables that link the agencies and customers to invoices/payments.
However, now that I've been thinking about the problem more, I think it might be beneficial to merge both agencies and customers into a single "Payee" table which would then be associated with payments/invoices. The payee table would only store a primary key. It would not contain actual names or info for the payee - instead I would pull that data via a JOIN with either the agencies or customers tables.
Regardless of whatever solution I choose I am still faced with the problem when creating a new payment record is that I need to scan both the agencies and customers table for possible payees. I'm wondering if there's a proper way to approach this from a database schema standpoint (or from an accounting/e-commerce standpoint).
What is the correct way to handle this type of situation? All ideas and possible solutions are most welcome!
Update 01:
After a few helpful suggestions (see below) I've come up with a possible solution that may solve this issue while keeping the data normalized.
The one thing about this method that rubs me the wrong way is that I will have to make multiple table selects to get a list of all the people who can potentially make payments and/or have invoices assigned to them.
Perhaps this is unavoidable though in this situation since indeed there are different "types" of people that can be associated with payments and invoices. I'm stuck with a situation where I have two different types of records that need to be associated to the same thing. In the above approach I'm using the FKs to link each table (Agencies/Customers) to a Payee record (the table that unifies both Agencies/Customers) and then ultimately links them to Payments and Invoices.
Is this the proper solution? Or is there something I've overlooked?
There are several options:
You might put this like you'd do it with OOP programming and inheritance.
There is one table Person which holds an uniqueID and a type (Agency, Customer, more in Future). Additionally you might add columns with meta-data like who inserted/when/why and columns for status/soft-delete/???
There are two tables Agency and Customer, both holding a PersonID as FK.
Your Payee is the Person
You might use a schema-bound VIEW with a UNION ALL to return both tables of your modell in one result. A unique index on this view should ensure, that you'll have a unique key, at least as combination of the table-source and the ID there.
You might use a middle table with the table-source and the ID there as unique Key and use this two-column-id in you payment process
For sure there are several more...
My best friend was the first option...
My suggestion would be: instead of Payees table - to have two linking tables:
PayeeInvoices {
Id, --PK
PayeeId,
PayeeType,
InvoiceId --FK to Invoices tabse
}
and
PayeePayments {
Id, --PK
PayeeId,
PayeeType,
PaymentId --FK to Payments table.
}.
PayeeType is an option of two: Customer or Agency. When creating a new payment record you can query PayeeInvoices by InvoiceId to get PayeeType and corresponding PayeeId, and then lookup the rest of the data in corresponding tables.
EDIT:
Having second thoughts now. Instead of two extra tables PayeeInvoices and PayeePayments, you can just have PayeeId and PayeeType columns right in Invocies and Payments tables, assuming that Invoice or Payment belongs only to one Payee (Customer or Agency). Both my solutions are not really normalized, though.
I have a following Class Diagram:
Customer
Id
Name
Email
Packages
Id
Name
ImageUrl
Price
Description
Products (One package may have 1 to many products)
Products
Id
Name
ImageUrl
Price
Description
Orders
Id
CustomerId
Address
How i can make relationship between Orders, Products and Packages. I am using Entity Framework 6 Code First with MVC 5 webapi.
Edited:
Customer can place multiple orders, One order is only associated with one customer
One order can contain multiple Products, One product may have multiple orders
Customer can order multiple Packages, One package can be ordered by multiple customers
Thanks
Customer - Orders have a one to many relationship. Will require ForeignKey CustomerId in Orders. So the above should do.
Orders - Products have a many to many relationship. Will require a many to many table (say, RelatedOrderProducts) with Foreign Key fields OrderId and ProductId of tables Orders and Products resp.
Customer and Packages are also a many to many relationship. So same as above there should be a many to many table (RelatedPackagesCustomers) with foreign key fields PackageId and CustomerId of tables Packages and Customers respectively.
I am not familiar with the Entity Framework, MVC, but this is a database design you may follow.
EDIT:
I may have misunderstood the third relationship. There are a few fixes that may work depending upon how you wish to access the data. One possible edit is to change the RelatedPackagesCustomers table to RelatedOrderPackages table and the Foreign keys accordingly. This way you will have two relations, order-packages and order-products that will save your order having combination of packages and products.
To save you should add a order and use the OrderId to add products and package relations in their resp. relation tables.
When you need to get a list of all the packages and products that a customer has ordered till date, you will do a query of Order with CustomerId and over it do two JOIN queries that will fetch you the packages from RelatedOrderPackages and products from the RelatedOrderProducts related to the particular OrderId (indirectly related to the customer).
I Need to Design a database for a system where there's Customers and Vendors but they both are related to entity called Users where every user is either a customer or a vendor .
the problem is that Vendors are related to other entities that Customers aren't .
so how can I design such a database ?
The other entities will store the ID of the Vendor as a foreign key. And Vendors and Customers are not going to be in the same table anyway*, so it's not like the two have IDs that might be used at the same time for that.
Also, to add, the Foreign Key you require for User could be managed as an add/edit trigger if your DB of choice allows it. That way you can make sure that the Vendor id used for those related entities isn't a User ID linked to Customers. (...WHERE userid NOT IN (SELECT userid FROM users WHERE customer = TRUE))
* Customers and Vendors have different properties/fields so shouldn't be in the same table.
You could have Vendors and Customers have a relationship to a User table.
user
===========
userId
name
vendor
===========
vendorId
companyName
userId
customer
===========
customerId
source
userId
Then you can link to both customers and vendors from the same table, yet they can still share the same common data in the user table. In fact, a customer could also be a vendor.
Your question could be generalized as follows: how do I express subclasses in relational tables?
For the generic answer, see this:
https://stackoverflow.com/tags/class-table-inheritance/info
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.