I'm trying to create a proper database layout for a project I'm working on, however I can't seem to work out which is best.
Basically the "app" is something where a User can be assigned to many Products, and a Product can be have many Customers.
From here, each Customer has a Service, which is specific to that Customer and Product.
A Service can have many Incidents, but an Incident can only be assigned to one Service.
A User can also have Incidents, but an Incident can only have one User.
Here is the two designs I have made for this:
http://i.imgur.com/ZcCFcdg.png
As you can see, the left design has a table specific tables for the Many-Many relationships, where as the right one has a overall pivot table for them all.
I see both of these methods working (in my head) - however since I'm not the best with this, are there any downsides to either of these methods? And do you see any problems I'll run into, in the future?
Also, is the right one even a proper way of doing it?
I'm also going to be using the Eloquent ORM.
Look up 'Third Normal Form'. This gives rules on how to design tables. You could take one or other of your current designs and apply the three rules to see where you get to.
I would say the one on the right is wrong: too much duplicate information, and unclear relationships. The one on the left is OK, but the two Many-Many tables are redundant. You know a Product and Customer are linked because it's in the Service table. You know a User and Product are linked because its in the Incident + Service tables.
Cheers -
After clarification, a User belongs to a Customer. In that case, add CustomerID to the User table - this is important data about the user and should be included. It will allow you to stop the User raising Incidents on Products not associated with the Customer.
This also will enable you to list the Products associated with the User via the Customer the User is associated with.
Further, the Customer should have it's ID on Product, and Service should have the ProductId, not the CustomerID, as the Service is associated with a Product and only with a Customer via the Product it is associated with.
Related
I'm designing database for an mobile-based ecom platform.
Currently, the system have one and only one shop. The design for the database of the system has the tables below:
User
Product
Category
Review
Order
Now, I want to scale up the system so that it can support multiple shops. User can sign-up as a seller and create their own shop, manage their own products and orders.
How can I design such a database from the original database which was designed only for one shop?
I have two options in mind but I have no idea whether they will works or not:
For each record in the table, I add a field shopId that ref to the id of the shop it belongs to. Then I will index this field to increase query's performance.
For each shop, I create a new collection/table to store the data that belongs to it. For example: shop1_product, shop1_order,... are the tables i will create for the shop1.
Are the approach above valid? Is there any other better approach.
P/s: I'm using MongoDB, and the system doesn't require operations across many shops.
Thank you guys!
I'm looking for a second opinion from maybe someone with more experience with SQL.
So I have a database that looks like this :
Company has multiple Clients which has multiple Projects which has multiple Tasks, etc.
In my application a user is assigned a company and cannot query information that isn't tied to it. So whenever a user tries to retrieve Client/Project/Task/Punch I need to make sure that my query contains a Where clause that looks like WHERE companyID=[user's company id]. This add a lot of joins when I need to fetch Punch since I need to go up the chain to see if the company is the same as the user.
Since a client/project/task/punch will never switch from a company to another one, I was wondering if there's any red flag to add a companyID field in project/task/punch in order to simplify the querying ?
I'm using PostgreSQL
If I understand correctly, what you are buildng is a multitenant system, where your companies are the tenants. If that is the case then there are no red flags - on the contrary, your main concern is to isolate data belonging to different companies in the most efficient and most secure way.
I find this old blog post to be a basic but clear introduction to multitenancy.
The recommended way to go was then, and is today, the third option: one DB, many schemas. I'm no Postgres expert, but I believe it supports that option quite well.
I'm using this forced "down time" to finally take my business from Excel to Access. I am fairly accomplished at Excel VBA etc, and pretty much run the business on a handful of highly developed Excel sheets I’ve created over the years. They work well, but they are not very scalable, and I want to get over to a proper relational DB.
I've taken an Udemy course on Access which was fine, but I’ve already hit some issues which may be fundamental misunderstandings, or just inexperience.
My first issue is that my company has projects (commercial contracts) which often, but not always, involve two ‘customers’ - an End User and an Agent. Agents and End Users can be interchangeable though, i.e. an Agent on one project might be the End User on another, so my “Customer Table” is simply a list of ALL my end users and agents with a CustomerID.
In my “Project Table” I have a CustomerID field and an AgentID field, both of which I wanted to use to pull out a customer and then agent from the single “Customer Table”. I can’t find the way to set up the relationships to enable me to do that – I can get either one, but not both for each Project Table query.
For a while I thought I needed a many-to-many relationship I needed, but I still don’t find how I can reference two entries from a single table in one record.
Thanks for any help!
You're almost there. What you need to do is to create a one-to-many join between tblCustomer and tblProject (based on tblCustomer!CustomerID=tblProject!CustomerID) and then another one-to-many join between tblProject and another instance of tblCustomer (based on tblCustomer!CustomerID=tblProject!AgentID). The relationship window should look like:
Regards,
We have a need to know which database architecture makes more sense to use and why.
We have a list of customers who are all going to use the same table structure (with very few exceptions).
We would have about 10 thousand customers who might all have all about 50 thousand products each.
The processing on products may not be the same for each customer and we would also want to provide a plan where customers could have API access to their data.
Our customers do sell products and their SQL table structure would all have columns such as :
Feed_ID
Product_ID
Product_Description
Price
Weight
etc...
The Feed_ID is used to differentiate the origin of these products and will be unique for each customer - of course.
The 3 choices of relational table structure that we have thought about:
Each customer has its own database and in that database, he has 1 table per product-feed
All customers are hosted under 1 unique database under which all customers all have 1 table per feed - in that case, 1 customer can have 2 tables if he as 2 different product feed.
All customers are hosted under 1 unique database, HOWEVER, in this 3rd solution, we only have 1 unique table that host all products feed of all customers.
Which solution would you use and why you think that the solution you selected is better?
Thank you.
You haven't quite provided enough information. Under almost all circumstances (see below for exceptions), you want one set of tables for all customers. Here are some reasons:
Performance. A proliferation of tables means the data is spread through more data pages, so you have lots of partially filled data pages. The database is bigger and processing is slower.
Coding efficiency. If the tables for a customer all have different names, then all the code is dynamic SQL. That is harder to maintain.
Maintenance. Adding a column or index is very arduous when there are zillions of similar tables.
Analytics. When similar data is spread through tables, it is really hard to answer questions such as "Which client has the most products?".
Security. Granting access permissions on a single set of tables is less error prone than on zillions of tables.
And no doubt, I've missed a few reasons. You can see that it is almost a no-brainer to have a single database with a small number of tables.
There are situations where separate databases might be called for. I cannot think of a good reason to have separate tables for each client in a single database.
The number one reason would be security and isolation. There might be a business or even legal reason for storing data into "physically" separate databases, to further minimize the possibility of one client seeing another client's data (accidentally or through hacking).
Another reason would be if clients had bespoke solutions. That is, there are per-client customizations. I would still be inclined to try to put this into a single database solution, but that might not be possible.
Related to this would be an application that you intend to support both in the cloud and on premises. In that case, separate databases per client would probably simplify the application design.
But, in general, you would store the data in a pretty normalized single database, with one table per entity.
I think having separate tables (or ideally schemas) for each customer is not that bad idea. In addition to benefits you mentioned, this way you can scale your database easily, and you can give customers full control of their data if they want to.
Regarding the drawbacks:
Managing it is more complicated but not as bad either - you can write
a script to create columns/tables/indexes/etc. You
don't have to do it manually.
It will be a challenge to perform analytics on 10K tables,
although it's not the best idea to mix it with production anyway.
I'd create a separate database (or server) for analytics, running
some overnight job to update reporting tables.
Also, if your table is going to have hundreds of millions rows (10Kx50k?), it's a good idea to split it into smaller pieces, regardless which option you'll choose. If not by customer, then by region or some other bigger group (assuming you are building on premises RDBMS)
Microsoft CRM 2015.. a great little customer management system, but why did do they leave suppliers out?
Anyway how do I create and manage suppliers using Dynamics CRM?
or do you need different software for that?
Cheers,
In previous versions I have created custom entities for Vendor and Supplier. Here are some of the setup I did, of course always depends on business needs.
1:N Supplier to Product relationship
Added fields for supplier details
1:N Contact to Supplier for POC at organization
1:N User to Supplier for POC within our organization
If you are not using the out of the box quote to order to contract process then you will need to accommodate for Product inventory and qty on hand limits.
Used Goals and Rollups to set minimum inventory levels and restock alerts
Make sure finance is involved in the design of this process as they may be particular about how reordering is handled. While users may want it automated there might be internal requirements, specifics on contracts with suppliers that require some additional review.
Created relationships for Contract and opportunity records
This was needed to improve reporting since you cannot report out on second tier relationships. For example - how many opportunities are coming related to this particular supplier who is delayed delivering. If the supplier relationship is not on the Opportunity record itself you cannot get to it.
These were the key items I thought mattered. There is always more, but you should not need to purchase an alternative supplier tracking software.