I am building a dynamic structure in a data base so that I can configure reports from backend dynamically. Need your help in designing the backend structure. Here is my idea
Table ReportAccountMap
AccountId
ReportId
IsActive
One account can map to multiple ReportIds, accountid is unique
Table Report_MetaData
StructureId
DataSetName
DataSetSourceId
DataSetSourceServiceAPI
Table Report_Structure
ReportId
StructureId
I am trying to find what constraints to put in the above structure.
Thanks in advance.
Add an id into ReportAccountMap and Report_Structure so your primary key there will be one-dimensional.
ReportAccountMap.AccountId needs to be a foreign key to Account(id)
(ReportAccountMap.AccountId, ReportAccountMap.ReportId) needs to be unique
Report_MetaData.StructureId needs to be a foreign key to Report(StructureId)
Report_MetaData(DataSetSourceId) needs to be a foreign key to DataSetSource(Id)
Report_Structure.ReportId needs to be a foreign key to Report(Id)
Report_Structure.StructureId needs to be a foreign key to (Structure.Id)
At least this is how I understood your intention. It would not hurt to add indexes for the n:m tables taking into account the optimal direction.
Also, ReportAccountMap is needed, since it is different from Account logically and it also has an attribute called IsActive.
Related
I want to construct this database. Here in category table we give ID primary key of the category table to foreign key of the category table. I understood this and I done this part also but see in product table we want to give ID primary key of the product table to product table as a primary key so how to do that? This is my question? We can't able to use the same syntax in the foreign key. I want to done this in SQL server. So kindly anyone help me to do this part.
The database looks ok apart from one thing:
One table, (product) has a 1:1-relation to itself. It makes no sense in any way.
1:1 relations are used between different tables and are great at times (customizations on 3:rd part systems etc)
What you probably want is a 1:n-relation to make one product act as a collection of other products, (also available as separate products). For this to work you must add a foregin-key field (nullable) in the product-table.
But that solution would probably be too limiting for the purpose above, since one product could only belong to one product. So what you want is a n:n relation. So what you need to do is create a new table as in:
product_part
============
product_id
part_product_id
This is called a junction table and both fields are used to make up the primary key.
However, junction tables may grow over time to regular tables as fields are added, so I would advice you to use a separate PK field (makes API-requests easier etc) as in:
product_part
============
id
product_id
part_product_id
position
qty
Hope this helps.
I'm trying to figure out the optimal way to create a database for a project. We're taking data from a bunch of projects and storing them into an RDBMS. One of the qualities of each project is the labels and users attached to each project.
Right now I have a table for users, a table for labels, and a table for projects that would ideally reference the PK IDs of the users and labels. I'm wondering which of these two options would be optimal for dealing with this data for use in an external resource like Tableau:
We could theoretically store the ID's of each label and user in arrays in their respective columns to make the tables more concise and easy to understand.
We have a separate column for each label and user and use bool values to show whether or not they're attributed.
Option 1 at first glance seems more attractive, but as we're using Db2 I'm not sure how feasible it is.
I understand there might not be enough information here. It's a pretty tight-lipped project so I can't give a ton of information away, but if you need more to offer advice, I can see what I can do. Thanks!
Neither. You would use junction/association tables:
project_labels
project_label_id primary key
project_id foreign key references projects(project_id)
label_id foreign key references labels(label_id)
project_users
project_user_id primary key
project_id foreign key references projects(project_id)
user_id foreign key references users(user_id)
I need to build a simple forum (message board) as a school project. But I came across one problem. In the img above there are 2 tables: post and category, which have many-to-many relationship. I made a bridge table, which stores the postKey and categoryKey. Is it a bad practice to create a composite primary key from those 2 keys, or I need something like postCategoryKey? And what else should I improve?
On my opinion, there is no need for PostCategoryKey, due to it's only a relationship table and you won't accés it by postCategoryKey.
I would create the PK using the 2 others FK (postKey and categoryKey).
Hope it helps!
It depends, if you plan later on to add some extra metadata to postCategoryKey in a separate table, then it makes sense.
In your case - I'd go with a composite primary key and get rid of postCategoryKey
You will have to make postKey and categoryKey not null and create a unique constraint on them anyway. That makes them a key for the table, no matter whether you call this the "primary key" or not.
So, there are three options:
Leave this as described with NOT NULL and the unique constraint.
Declare the two columns the table's primary key.
Create an additional column postCategoryKey and make this the primary key.
The decision doesn't really matter. Some companies have a database style convention. In that case it's easy; just follow the company rules. Some people want every table to have a single-column primary key. If so, add that PK column. Some people want bridge tables to have a composite primary key to imediately show what identifies a row. My personal preference is the latter, but any method is as good as the other actually. Just stay consistent in your database.
I'm working on a project and I'm new to both web apps and SQL, so bear with me. I'm building an API and I want to make sure that my users only have access to certain rows in a specific table that have a foreign key to their customer id in another table, but have to be validated by user id in another table. (A single Customer has multiple Users and owns multiple Assets. For right now, all of the Customer's Users can access any Asset, but no Customers share an Asset or User.) The way I can think to do this is to do
SELECT * FROM [Asset] WHERE Id=#AssetId AND CustomerId=(SELECT CustomerId FROM [User] WHERE UserId=#UserId);
This is great, but with many entries in the Asset and User tables, this query could take up a ton of time. This is bad since every request made to my API that needs the Asset data should be doing this check. I could set up an index, and in fact UserId is a Secondary Key in User because it's a unique identifier from the auth provider, but I'm not sure if I should add an index for CustomerId in Asset. The Asset table should grow relatively slowly compared to some other tables (have a messaging record table for auditing purposes), but I'm not sure if that's the right answer, or if there's some simpler answer that's more optimized. Or is this kind of query so fast at scale that I have nothing to worry about?
For your particular case, it looks like the perfect context to build a junction table between the User table and the Asset table. Both field together will become the primary key. Individually, AssetId and UserId will be foreign keys.
Let's say the junction table is called AssetUser.
Foreign keys :
CONSTRAINT [FK_AssetUser_User] FOREIGN KEY ([UserId]) REFERENCES [User]([UserId])
CONSTRAINT [FK_AssetUser_Asset] FOREIGN KEY ([AssetId]) REFERENCES [Asset]([AssetId])
Primary key :
CONSTRAINT [PK_AssetUser] PRIMARY KEY([AssetId], [UserId]));
You shouldn't worry about scale too much unless you are going to have ALOT of data and/or the performance is critical in your application. If so, you have the option to use hadoop or to migrate to a NoSQL database.
In SQL Server 2012, I have a User table to store application users. I also have an Organization table which has a LastModifiedBy field in which I would like to store the UserID of the last person to modify the values within the table via an ASPX page. Should I create a foreign key relationship between the LastModifiedBy field and the UserID field within the Users table?
I would also like to add a LastModifiedBy field to the Users table itself. Should/can I create a self referencing foreign key constraint on this table? If this is possible, is it a horrible idea?
Any perspectives on pros and cons of creating these foreign key constraints would be greatly appreciated.
What you are describing is what foreign keys are made for. These foreign keys are at the very core of relational databases. Even if they might give a slight performance impact when inserting new rows, because it has to check if the referenced key exists, it should not be avoided.