I asked a more generic question yesterday and done some work based on this. This question is more to the point in regards to something I am trying to work out.
So my application has a departments table to handle departments. So I am able to make different departments within my application such as Marketing and Finance.
The problem is, I know what departments I need to make, and these will be created beforehand (but I have made it like a CMS so an admin can edit departments etc). With the departments created, I envision something like this
So a user can choose the department from a dropdown (remember, this is after departments are created). When they do this, the document dropdown should populate.
This is my problem, how can I associate specific documents to a department? Each document requires different inputs, so I would imagine they need to be different tables? At the moment I have
But this doesnt really solve my problem whereby I can state that the Marketing department has a Brief document and Overview document.
How could I go about doing this seeing that I do not specifically have a table for each department? Would I need to create one for each department?
Thanks
You can do the following:
If the variety of the document's information you need to store is to large
create a table which has 5 columns:
id,department_id,crated_at, updated_at, property
so for each property you will have a record in the table e.g:
id department_id crated_at updated_at property
1 454 2015-08-20 2015-08-22 x:34
2 454 2015-08-26 2015-08-26 z:234
3 934 2015-08-25 2015-08-26 y:45
This way you won't need table for each document type
EDIT: another option is adding one column for property name and one for it's value
id,department_id,crated_at, updated_at, property_name, property_value
Related
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 am making an application that will process a big chunk of information. This information was retrieved using some web crawlers and is about news, containing data such as News Title, URL, Publication Date, Category and Content. The crawled data is in XML format, and I will load that information into my application.
From there, 10 users will process every news and tag the category of the news manually by reading the title. I've used 9 main categories to be used, and for each news the users will decide from 0-5 how much this particular news belongs to each category.
Users will also search for news by title and decide if this news is discussing the same event as another news, or if this news is similar to another news (like a news about a football game at 3 PM and a news about a football game at 5 PM).
I have no problems with making the application itself, I just need some help with the part of how to design one/many tables that can link news that talk about similar events or about the same event, since there can be many many news that can talk about the same event.
So far I've done something like this:
Table News
ID
Title
URL
PublicationDate
NewsContent
Table Category
NewsID
User_ID
Economy
Politics
Present_Day
Sport
Technology
Showbiz
Culture
Region
World
Table User
ID
FirstName
LastName
Each category field in the Category table holds a tinyint data type (I'm using SQL Server) and I've restricted the values the user can input via a check constraint so that it allows values from 0 - 5. I don't know if this is the right approach so far for the database design, and I need to add the table/s that allow to add information about similar news or news that talk about the same event, such as a table Similar_News containing some fields like News_ID, SimilarNews1_ID, SimilarNews2_ID and so on, and must contain the information about which user 'said this', but this sounds like a flawed design to me.
Any help is appreciated, thank you.
Here are some suggestions. In the CATEGORY table you have created 9 different columns (economy, politics etc). What if a few days / months / years down the line there is a new category. In this case you will have to modify your database design. Instead, you could have the following structure of your CATEGORY table.
CategoryId
Category
And have one more table to store the actual news categorization.
Table: NewsCategory
NewsId
CategoryId
CategoryWeight (This will store the rating from 1-5)
If the user feels that a news does not belong to a particular category then no row will be inserted in this table for that category. Such a structure will give you more flexibility to insert new categories in future without changing the database design. You just have to insert new rows in the Category table.
For storing similar news I would recommend one of the following approach.
Create a table event and store the details of the event in this table.
EventId
EventDescription
Sample Data
EventId: 55
EventDescription: Euro 2016 Belgium vs Italy
Now you can include this EventId in your News table. This way you can pull up all the news that are related to this event.
Create Similar_News table with n fields to store the similar News_Id doesn't sound a good idea. How many fields would you create? 3? 10?
You are modeling a n to m relationship so I would only use two fields (three if you wanna store the User Id). For example if New 1 is similar to news 2 and 3. And New 3 is similar to 4, you insert the rows:
New_ID SImilar_New_Id
--------------------------
1 2
1 3
3 4
Another approach would be use a NOSQL DB to store flexible structures, for example:
"News":{
"User_Id":1,
"Category"{
"Economy":3,
"Politics":4
},
"Similar_News":[1,2,3]
}
I am building a tool to allow people to create customized reports. My question resolves around getting the right database schema and design to support some custom report settings.
In terms of design, I have various Slides and each Slide has a bunch of settings (like date range, etc). A Report would basically be an ordered list of slides
The requirements are:
A user can create a report by putting together a list of "Slides" in any order they wish
A user can include the same slide twice in a report with different settings
So I was thinking of having the following tables:
Report Table: Id, Name, Description
Slide Table:, Id, Description
ReportSlide Table: ReportId, SlideId, Order, SlideSettings
my 2 main questions are:
Order: Is this the best way to manage the fact that a user can order their slides on any given report
SlideSettings: since every slides has a different set of settings (inputs), i was thinking of storing this as just a json blob and then parsing it out on the front end. Does anything one think this is the wrong design? Is there a better way to store this information (again, each slide has different inputs and you could have the same slide listed twice in a report each with different settings
Order: Is this the best way to manage
It is the correct way.
SlideSettings: ... storing this as just a json blob
If you never intend to query these values, then that's fine.
You may want to rename ReportSlide to SlideInReport. A relationship should not just list the referenced tables, but the nature of the relationship.
Some (me) prefer to give PK-columns and FK-columns the same name. Then you cannot get away with just Id, but you need to call them sld_id, rep_id.
May be you should have a Settings table. You may also need a ValueTypes table to define which setting can take what kind of values. (such as Date Range). And then let the list of setting IDs be stored against a slide.
Needless to say, these "best way"s will depend on type and amount of data being stored etc. Am a novice in JSON etc, but as far as I read, it's not a good idea to keep JSON strings as database fields, but not a rule.
I think, from a high level view, your schema will work. However, you might consider revising some of the table structure. For example:
Settings
Rather than a JSON blob, it may be best to add columns for each setting the ReportSlide table. Depending on what inputs you allow, give a column for each. For example, your date range will need to have StartDate/EndDate, Integers, Text fields, etc.
What purpose does the Slide Table serve? If your database allows a many-to-many relationship between Slides and Reports, then the ReportSlide table will hold all your settings. Will your Slide Table have attributes? If not, then perhaps Report Slides are all you need. For example:
Report Table: ReportID | DateCreated | UserID | Description
ReportSlides Table: ReportSlideID | ReportID | SlideOrder | StartDate | EndDate | Description...
Unless your Slide table is going to hold specific attributes that will be common across every report, you don't need the extra joins or space.
Depending on the tool, you may also want to have a DateCreated, UserID, FolderID, etc. Attributes that allow people to organize their reports.
If the Slides are dependent on each other, you will want to add constraints so Slide 2 cannot be deleted if Slide 3 depends on it.
Order
Regarding order, having a SlideOrder column will work. Because each ReportSlideID will have a corresponding Report, the SlideOrder can still be changed. That way, if ReportSlideID = 1 belongs to ReportID = 1 and has specific settings, it can be ordered 7th or 3rd and still work.
Be aware of your naming convention. If the Order column is directly referencing Slide Order, then go ahead and name it SlideOrder.
I'm sure there are a million other ways to make it efficient. That's my initial idea based on what you've provided.
Report Table: ID (Primary Key), Name, Description,....
Slide Table: ID (PK), Name, Description,...
Slide_x_report Table: ID(PK), ReportID (FK), SlideID (FK), order
Slide_settings Table: ID(PK), NameSetting, DescriptionSettings, SlideXReportID (FK),...
I think that you shoud have a structure like this, and in the Slide_settings table you will have the setting of the differents slides by reports.
Imagine that the slide_settings table may contain dynamic forms and these should relate to a specific slide of a report, in this way you can have it all properly stored and the slide_settings table, you would have only columns that are needed to define an element of slide.
I have a noob question but he, i'm learning :-)
I'm making a form with the following tables 1 tblCustomers and 1 tblWorkorders.
My question is:
When I add a customer to a new record, this person is stored in the table: tblCustomers this is going fine.
The problem is that I also have a table: tblWorkorders, in this table I store all the technical information, sollutions and the customers belongings. (adapter, notebook bag etc etc)
My problem excists when for example a customer named John Doe comes back with another problem 2 weeks later. In the table tblWorkorders should be 2 records with the problems of John Doe I think it has something to do with relationships between the tables, can someone tell me where to find a good example or when it's a short story, how to do this?
Very difficult to explain this concept and start you off from scratch. Be prepared for further research on different item. Here is a place to start: http://office.microsoft.com/en-us/access-help/guide-to-table-relationships-HA010120534.aspx
The following is how you would use your tables:
You need to have a common field in both tables (it can be more than one field, but let's keep it simple). The easy way is to have a CustomerID field that is a Data Type field set to: AutoNumber (It does just what it says.).
tblWorkOrders will have the same field (doesn't have to be the same name, but let's keep it simple) BUT, the Data Type is: Number Field Size: Long Interger.
If you're able to use: Database Tools | Relationships, and join the two tables by this field, developing forms and reports is a lot easier.
Your form will be based on the tblCustomers table (I know, let's keep it simple.) and a Sub Form will use the tblWorkorders table and the 'Link Master Fields' and the 'Link Child Fields' will use the CustomerID from each table.
First post, please be kind.
NOTE: I have reviewed entry #20856 (how to implement tagging) but feel this is different due to the fact that the tags method I'm considering is organization specific in my app. I’m hoping someone can confirm the direction I’m going or point out some other options.
(background) We are building a web application that gives different organizations visibility to their inventory in different locations. The database stores users, organizations, sites, and items and there are links from sites and items to organizations that allow us to determine which items / sites to show to which users (based on their organization).
It is common for two (or more) organizations to want to use the portal to check on the stock status of (for example) Widget A in the Los Angeles Warehouse. That part is fine. However, the different organizations also track unique information about Widget A. For example, Org 1 wants to track the color, volume, and primary vendor for each item. Org 2 wants to track Color, Stock Type, Inventory Cycle, Buyer Code for each item. I want to avoid a situation where I have to have a table loaded with all these possible fields and then figure out which organizations use which fields.
I’m considering using something along the lines of tags, but adding a tag category, and having the tag category be defined at the Org level. So, the basic table structure would be something like:
Table: OrgTagCategory
Fields: OrgId, TagCategoryId, CategoryTitle
Table: OrgTag
Fields: OrgId, TagCategoryId, TagId, TagTitle
Table: OrgItemTag
Fields: OrgId, ItemId, TagId
Then, when the user logged in the main dashboard the grid would include their appropriate item fields as columns in the grid. So, from above example, Org 1 would see Item#, Description (would be shown for all), color, volume, and primary vendor. Org 2 would be shown Item#, Description, Color, Stock Type, Inventory Cycle, Buyer Code.
Am I overthinking this or is there a simpler method of doing this that I’m missing? All thoughts / feedback sincerely appreciated.
That should be no problem, but you're storing the OrgId redundantly. Also it seems like there could be some overlap (probably a lot of overlap, realistically) between tags and orgs.
Here's how I'd do it:
Table: OrgTag
Fields: OrgId, TagId
Table: Tag
Fields: TagId, TagTitle
Table: ItemTag
Fields: ItemId, TagId
This way each org is associated with the tags it's interested in, but you don't have redundant tags. A given tag that's used by multiple orgs just gets a bunch of rows in OrgTag, instead of multiple rows in Tag with the same TagTitle.
You'd only need a table OrgTagCategory if there were multiple tag categories per org. But you haven't described this extra association as a requirement.
Based on your description I sketched a simplified model and combined it with the observation pattern. This should enable you to track various item properties and user preferences for viewing them. Admittedly, the Preference table may grow large, but data has to be stored somewhere anyway, and you may retrieve it using sql, which simplifies the business layer.
- Organization and person are types of users. User table has columns common to all users, while Organization and Person tables have columns specific to each one.
- A stock item (widget class) can be found at several sites (warehouses); a site stores many items.
- One item belongs to one user; a user can own many items.
- Measurement and trait are types of observations. Measurement is a numeric observation, like height. Trait is a descriptive observation, like color.
- An observation is of a specific type (height, weight, color), there can be many observations of the same type.
- One item (widget class) can have many observations, an observation relates to one item only.
- A user can prefer to display many observations; an observation may be preferred (to display) by many users.
UPDATE
We could simplify user's subscription to item details (observations) by tagging observation type, for example height, weight, width would be tagged with: all, dimensions, physical. Some other tags would be: accounting_interest, tracking_specific, etc. A user would then subscribe to tags only. Tags (could) form a hierarchy with ALL at the top.
- One observation type (height, weight, color) can have many tags, one tag belongs to many observation types.
- Each tag may have a parent tag forming a hierarchy.
- A user stores preferences for a set of tags that she usually monitors.
UPDATE 2
Now we can sort out who is who and who owns what. In this modification a user (now a person) can work for more than one organization (having several part-time jobs or contracts). An item belongs to a organization now. A logged-in user can see all items from all organization that she works for.
My first quick thot on this would be that - if this is just limited to 'showing' particular fields to particular Orgs on Dashboard then it is better to handle it on the App side. If there's any other usage of 'tagging' then pls clarify.
Here's a simple approach -
You can store a field [OrgDashboardFields] in the Org master table or the OrgItem table. This will be a comma (',') separated list of fields to be shown on the dashboard. At run-time fetch the [OrgDashboardFields] field and parse the comma separated list in the app and make the Dashboard Grid behave accordingly.
Or, if there's a dynamic-query framework then based on the [OrgDashboardFields] field you can create a dynamic SQL-query and get the desired result which is purely Org specific.