SQL Create Trigger On Tables That Are Added By New Users? - sql

Hope someone can guide a noob as I have done alot of googling and searching here as well but here's what I am trying to accomplish.
I have a program that upon registering it creates a table that is yours in the database. A workerID is generated upon registration on that workerID gets attached the table name that gets created for you.
For example after you register you get assigned a worker ID number of 10001. A table is then created for you named DB_10001.
Easy enough.
Within Table DB_10001 there is a column that Identifies who the project creator was (ID'd by workerID).
Worker ID: 10001 creates his or her own projects but sometimes, a project is assigned by another workerID and it is placed in DB_10001 table.
I want to create a trigger that if the PROJECT CREATOR (which is a column in DB_10001) is not the owner of the table (WorkerID: 10001), to be notified that the owner of that table (10001) of a pending project to they can either accept or reject.
Is it possible to put this trigger when the table is created???
Thanks in advance,

Related

how to avoid creating new columns in database

I have a table of dentists and services. And I want it to be dynamic so I have added a "add services" function. but how can I normalize it if services are not defined yet? since I didn't add yet.
the solution I've made is that I created a new table which is specialty where it creates new column every time I added a new service. But I dont know if it's very improper to create a new column within the add services function itself. But that's the only way I think. Are there any ways to solve it?
Dynamic columns are not good at all!
Tables should be static to be reliable.
Use relation-tables instead.
Example
You have a dentists table. It has an id column as primary-key.
Create a services table. Of course it should have a primary-key. besides that, put a dentist_id column. This will contain the id of the dentist in the dentists table.
If you provide more information and code or database schema, we maybe able to help more.
EDIT
As ADyson mentioned, if it is possible that multiple dentists work on one service, do a many-to-many relation.
Example
You have a dentists table And a services table. They both have an id column as primary-key.
Create a r_dentist_service table. Of course it should have a primary-key. besides that, put a dentist_id column and a service_id column. These should contain the respective IDs. This table will relate dentists to services.

sitefinity create a unscribers table in the database

Sitefinity by default create many necessary tables automatically for users , but it wont store the deleted subscriber information by creating a unsubscribes table. Are they any way to customize a new table in back end code to store deleted information?
When a user unsubscribes from a newsletter, then the user is removed from the relevant Mailing List (sf_notif_subscriptions table, which is a linking table containing subscriber_id and mailing_list_id).
Then, a record is being added to the sf_unsubscription_info table.

3 Level authorization structure

I am working on banking application, I want to add a feature of maker,checker and authorize for every record in a table. I am explaining in below details
Suppose I have one table called invmast table. There are 3 users one is maker, 2nd one is checker and last one is authorize. So when maker user creates a transaction in database then this record is not live (means this record can not be available in invmast table). Once checker checked the record and authorizer authorized the record the record will go live ( means this record will insert in invmast table ). Same thing is applicable for update and delete also. So I want a table structure how to achieve this in real time. Please advice if any.
I am using vb.net and sql server 2008
Reads like a homework assignment.....
Lots of ways to solve this, here's a common design pattern:
Have an invmast_draft table that is identical to invmast but has an additional status column in the table. Apps need to be aware of this table, status column and what its values mean. In your case, it can have at least 3 values - draft, checked, authorized. Makers first create a transaction in this table. Once maker is done, the row is committed with the value "draft" in the status column. Checker then knows there's a new row to check and does his job. When done, row is updated with status set to checked. Authorizer does her thing. When authorizer updates the status as "authorized" you can then copy or move the row to the final invmast table rightaway. Alternatively, you can have a process that wakes up periodically to copy/move batches of rows. All depends on your business requirements. All kinds of optimizations can be performed here but you get the general idea.

Timesheet Database schema

There is an old timesheet application being used in my company and i am going to rewrite it in asp.net.
There are other tables which can be linked to new Timesheet table like employee table but my main concern here is the Project and Project_Activity table.
In the current system, there is a one project and a activity table which are linked to the timesheet table seperatly and user has to spend alot of time on selecting activities code they worked on for specific project.
I have came up with the new idea; Project manager will have to fill up a project template and link all the activities code with the one project before starting this project. This way user will have to select the project only and it will automatically bring the associate codes for them.
Here is the logical schema design.
I like to know if this design will work okay? and is it okay to link Project_Activity table with timesheet?
PROJECT
PK_PROJECT_ID,
NAME
PROJECT_ACTIVITIES
PK_PA_ID,
DESCRIPTION,
FK_ACTIVITY_ID,
FK_PROJECT_ID
ACTIVITIES
PK_ACTIVITY_ID,
DESCRIPTION
TIME_SHEET
PKID,
EMP_ID,
FK_PK_PA_ID,
DATE,
HOURS
PROJECT --> PROJECT_ACTIVITIES <-- ACTIVITIES
|
|
|____TIME_SHEET
Note: Timesheet table has many other fields which are not a part of this question.
I'm assuming an Activity can refer to only one Project?
If so, you don't really need the Project_Activity table, just put the foreign key to the Project table in the Activity table.
If an Activity can refer to more than one Project, then your schema is fine, you have effectively decomposed the many-to-many relationship between Project and Activity. :)
In general the schema is OK. I would not use the naming convention you have, as I find it hard to read. No harm in using full words, but that's an aside.
What I would change is the Timesheet table. Do this instead:
PKID,
EMP_ID,
FK_PK_PA_ID,
STARTDATE,
ENDDATE
This will allow you to easily query who was doing what during a given time more easily. You can also allow records to have a NULL ENDDATE to show an activity currently being worked on.
I would add a trigger to make sure that for the same EMP_ID, a record's STARTDATE and ENDDATE never come between a STARTDATE and ENDDATE of other records (no overlap).

merging data from 2 databases

Currently have a contracts system that pulls in job data from our finance system. Each job has an id and the contracts hang off of that. We now have to bring in job data from another finance system. The jobs from the new system will also contain a job id and contracts will have to hang from this. I expect there will be some id conflicts when the data is merged. Whats the best way to deal with this. Should I create another table that pulls in the job data from both and assigns a new id for the contracts to hang from. Obviously I will need to update the current contracts to match the new id's generated. Does this sound like a good idea or is there a better way.
Given your additional comments, I would suggest that you use a mapping table to map any of the conflicting IDs in the old system to new IDs. Normally when importing data into an existing system you would want to keep the IDs of the current system intact, but since that system is going to be gone in a year (or however long it takes) and is about to be read only I would think that you would want to try to preserve IDs in the new system.
Once you create the mapping table, you would then use that to update any foreign key references, etc. and then import the new data, which should now have no conflicts.