Let's say I have a database where I store the users tasks.
To simplify lets say that a task has:
id
status (New, To do, In progress, Done, Rejected)
description
owner/creator
Now what I want to achieve is when a user finishes a task - makes it Done or Rejected, I want the user to provide some info about that state change. I imagine a popup with two fields: one to choose from Done/Rejected statuses and a textfield area to fill in the reason if you will.
The problem I have here is: how do I store the information about the task completion?
My idea is to create a table like task_completions which will have:
id
task_id
comment (varchar or whatever)
Now the thing is: when I load a task for a user from the database and I see it's completed (again, Done or Rejected) I need to load the information about the task completion. So it would result in two API calls:
get task
get task_completion, where task_completion.task_id == task_id
There's of course another way - I can add a task_completion field to my task table. And of course make it nullable, since it won't be filled with anything until the task is completed. And then I won't have to make two API calls, since when using something like Django serializers (or something like this), I will be able to "expand" the task_completion field from just a plain number (id from task_completion) column to a full nested JSON with information about the completion (id, task_id, comment) - I just have to call get task. And then I don't even have to provide the task_id field in the task_completion table.
So summing up, I think that I have 3 choices:
task and task_completion tables, where task_completion table contains the task_id column - two API calls
task and task_completion tables, where task table contains task_completion_id column - one API call if I do it right
task and task_completion tables, where task table contains task_completion_id column and task_completion table contains a task_id column - still one API call I guess - but does it make sens to have both of those columns in those tables?
Related
I have a script component in SSIS that parses the data into 3 outputs, which in turn are inserted into three tables. The problem is that one of these tables is a foreign key table and depends on the first two tables having their rows inserted first. Put another way, it would look like this:
Person
--------
Id
Name
Age
Job
--------
Id
Job Title
Hourly Pay
PersonJob
--------
PersonId (FK to Person.Id)
JobId (FK to Job.Id)
How can I have my Script Component insert the parsed output into the Person and Job tables first, and then the PersonJob table after?
Since I have complete control over the data being parsed into these tables, I ended up creating two Execute SQL Commands in my task flow.
Basically, before my package started on the data flow, I would remove the constraint. Then, once the data flow was complete, I would enable the constraint again. I'm not happy with the process, as I don't like to have to mess with the constraints when it's simply a matter of inserting them into the table in a specific order.
However, I do think it's a lot more efficient than having to parse the data twice or use a staging table. Either way, thanks for the advice!
I'm making a bot that receive and send images, i have to keep track to which image is sent to who so it send it only once. An user can also flag the image as inappropriate.
I made a db with 2 tables:
userTable with userID and userName
imageTable with imgID, fileName, fileCRC
I can think only of:
a) add viewedBy to imageTable "user1,user213,user9"
or
b) add imageToView to userTable "123,545,21321,654565"
But if I do [a] there is the problem that the more images a user views the more time is needed to get one random image.
And if I do [b] I already have a list of unseen images so I can just pick one random from here then delete the id. But if one user flag it as inappropriate I have to loop/remove the id from all the user in the db...
There is any better way?
You need an intermediate table that keeps track which user has seen which image. So basically this new table, let’s call it imageByUser, would contain a user id, an image id, inappropriate boolean flag, dateseen datetime (optional but would be useful on the long run) and a generated primary key (or you can have the combination of the user, the image and the dateseen as a composite logical primary key instead).
Having this third table would solve all your problems as you would just add a new row when someone sees an image. Also if they mark it as inappropriate m all you have to do is update the inappropriate flag to yes. This way you could even keep track of the cases when a user happens to see the same image twice (just add another row to the table).
I know it's old technology (ancient now), but it's what I have to work with due to work.
I am able to create a Group and report and link it to a textbox to provide a collapsible report, with master data and detail data.
What I want to know, is it possible in SSRS2005 to create another sub-group to the first group?
i.e. Master record -> Detail -> Sub-details
Every time I try and add another detail row for example I only get one row of data in the sub-group, because it's tied to the Details Grouping. I cannot explicitly say "report grouped by this other subgroup" (where it offers you to create groups in the Group list).
Yes I am trying to do this in a table.
This is what I am after...
[+] Col1 Col2 Col3 Col4
[+] data data data data
Col1 Col2 Col3 ...
data data data ...
...
...
The [+] is what I want to set up to allow the expansion of another group within the first group.
The answer is not to try and pack too much into one reporting object. In this case the Table object.
I managed to have far more flexibility by placing the tables and fields inside a List object.
Try these...
Drop a List item into the report
Define the Dataset to your main dataset that contains all the data.
Note: For this to work you need a query that have as much as the master and detail data inside as ONE query, so obviously your master data will repeat as deep as it has to, to get to the lowest common dataset, which in my case was the action items per student.
The List object will act as the Master data reference for all your other objects inside of it.
Now you can play! Drop in a few textboxes to show the data for the master data you want to only show ONCE per "logical record". I'll let you ponder what that meant!
Now to show subgroups, you'll need Tables for each one. Drop a Table object
In each table (group) don't specify a dataset, as I said above, all the data comes from the List.
But for each table, you'll need to define your Details Grouping. Go ahead and simply state the group parameters you require for the sub-group. So in my case, I want to display ONE row of Students, but any amount of Actions each student has. So place a StudentID for the student and an ActionID for the actions as a combined grouping.
Repeat the above for any other groups, and define their groupings so you don't get repeatitive data. One table could only have one pivot or group, so just define the index for that inside the Details Grouping. Do not use the Add.. feature to add groups, because you'll be adding groups within subgroups and go into another level again! Beware.
I hope this made sense.
I have a problem in creating a table for a database. I want to record many status for each farmer for example farmer will perform many procedures in paddy farming and have about 26 procedures from cultivation until harvesting.
So, each farmer must follow a schedule for each procedure according to dates fixed by Agriculture assistant. My problem is how can I record this procedure status to record whether the farmer is following the schedule or not? For now, I use the 26 procedures as the attributes for the activity table so in the activity table I have attributes
farmerID, status1 (for activity 1 eg: Cultivation) ,
status2 (for activity 2 eg: fertilization),
status 3
and so on until status 26...so is this the correct way? My lecturer says it is incorrect because so many attributes are there. Can you help me out from this problem? I can't think about this any more.
Not a good way of handling it, especially since it's not immediately scalable without adding new fields (and having your code map those new fields). I'd do something like this:
tbl_farmer
- farmerId
tbl_status
- statusId
- name (i.e. Cultivation, etc.)
tbl_activity
- farmerId
- statusId
And each time a farmer performs a status update, you place the entry inside tbl_activity. Basically tbl_activity is a reference table
An alternative approach would be to give each activity (procedure) an id and instead of many columns only have three.
farmer_id
activity_id
status
Assuming that your activities are stored in a separate table.
I have many tables in my database which are interrelated. I have a table (table one) which has had data inserted and the id auto increments. Once that row has an ID i want to insert this into a table (table three) with another set of ID's which comes from a form(this data will also be going into a table, so it could from from that table), the same form as the data which went into the first table came from.
The two ID's together make the primary key of the third table.
How can I do this, its to show that more than one ID is joined to a single ID for something else.
Thanks.
You can't do that through a trigger as the trigger only has available to it the data that you already inserted not data that is currenlty only residing in your user interface.
Normally how you handle this situation is that you write a stored proc that inserts the meeting, returns the id value (using scope_identity() in SQL Server, but I'm sure other databases would have method to return the auto-generated id as well). Then you would use that value to insert to the other table with the other values you need for that table. You would of course want to wrap the whole thing in a transaction.
I think you can probably do what you're describing (just write the INSERTs to table 3) in the table 1 trigger) but you'll have to put the additional info for the table 3 rows into your table 1 row, which isn't very smart.
I can't see why you would do that instead of writing the INSERTs in your code, where someone reading it can see what's happening.
The trouble with triggers is that they make it easy to hide business logic in the database. I think (and I believe I'm in the majority here) that it's easier to understand, manage, maintain and generally all-round deal with an application where all the business rules exist in the same general area.
There are reasons to use triggers (for propagating denormalised values, for example) just as there are reasons for useing stored procedures. I'm going to assert that they are largely related to performance-critical areas. Or should be.