Here is quick overview. I have an employee database with ID, name, phone num, division, location etc. It will all get stored in a table in a database called EMP. Now i have another Database that is central to other apps that may use it for a look up that contains all the divisions and locations. I want to use a lookup for division and location and this resides in another database on the same server that stores the information. When i use a datagrid and bound controls for my employee table. I can change the columns to drop downs but i want to point it to another db and lookup table, with still creating the foreign relationship so when i update the lookup (source) it will update the other applications db. whats the easiest way to do lookups to other database tables to pull back information and set it. any ideas.
Assuming you are following NORMAL FORM, the only thing on the employee database that references the Location and Division tables is an ID, which would never change, only be deleted. Therefore you can create DELETE triggers on these tables that will do whatever you think it should do to the employee table when a Location or Division is deleted.
Just make sure you have the security setup so whoever can delete from the Division/Location tables can also perform the coded action on the employee table.
Related
In my application I'm creating a case having a supervisor, but as the supervisor can be either an employee or an external supervisor, I'd like to be able to save either an employee id for the internal reference or a string for the name of the external supervisors name.
How should I implement this? Is having a table "case" and the sub-tables "case_internal_sv" and "case_external_sv" the way to go?
There's not a lot of information in your question on which to base an answer.
If there is common data and functionality across all types of supervisors then you will probably want one table to hold that common data. That table would establish the primary key values for supervisors and the case table would have a foreign key into this table. Information that is unique to either internal or external supervisors would go into separate tables and those tables would also have a foreign key back to the common supervisor level data.
This design is superior because you only have one place to go in order to find a list of all supervisors and because you can enforce the supervisor / case relationship directly in the database without a lot of code or additional constraints to ensure that "one and only one" of two columns is populated.
It's sufficiently superior, from a database point of view, that I'd consider using this design even if the data for internal and external supervisors is completely disjoint (which it's unlikely to be).
If your database allows you to define multiple primary keys you could have field employee and field employee_type combine to form the unique primary key. If not you could have an autogenerated primary key for the table and have a field for employee type and a field for employee_id.
What database are you using?
Having tables too normalized can do more harm than help. You should evaluate the benefits/drawbacks of having sub-tables based on your requirements.
A simple solution can be to have a 'sv_type' column in 'case' table. And have two columns
'internal_sv_id', a nullable foreign key to the employee table
'external_sv_name', a nullable string to save external name.
Then check for supervisor in one of these two columns based on the 'sv_type'
This design might not fully conform to 3rd normal form, but it can save lot of costly joins and allow integrity with employee table.
As for me, I'd go for the simplest solution in case of doubt.
I have few tables to store company information in my database, but I want to focus on two of them. One table, Company, contains CompanyID, which is autoincremented, and some other columns that are irrelevant for now. The problem is that companies use different versions of names (e.g. IBM vs. International Business Machines) and I want/need to store them all for futher use, so I can't keep names in Company table. Therefore I have another table, CompanyName that uses CompanyID as a foreign key (it's one-to-many relation).
Now, I need to import some new companies, and I have names only. Therefore I want to add them to CompanyName table, but create new records in Company table immediately, so I can put right CompanyID in CompanyName table.
Is it possible with one query? How to approach this problem properly? Do I need to go as far as writing VBA procedure to add records one by one?
I searched Stack and other websites, but I didn't find any solution for my problem, and I can't figure it out myself. I guess it could be done with form and subform, but ultimately I want to put all my queries in macro, so data import would be done automatically.
I'm not database expert, so maybe I just designed it badly, but I didn't figure out another way to cleanly store multiple names of the same entity.
The table structure you setup appears to be a good way to do this. But there's not a way to insert records into both tables at the same time. One option is to write two queries to insert records into Company and then CompanyName. After inserting records into Company you will need to create a query that joins from the source table to the Company table joining it on a field that uniquely defines the record beside the autoincrement key. That will allow you to get the key field from Company for use when you insert into CompanyName.
The other option, is to write some VBA code to loop through the source data inserting records into both. The would be preferable since it should be more reliable.
The only way I can think of doing it, since what I want to do is have a database of all the companies, and their respective information, then have another database per each company that sorts their orders and jobs, Is there a cleaner way than creating a table for each element in the company list table? If not, how would I go about doing this?
create trigger on yourdb for insert
then inside the trigger
create table and insert int it the specific row
Your question is a bit confusing. It seems that you may want to add the company id as a key on all the relations that exist. This would allow you to keep various company information in the same table structure and select from it by filtering on the company id.
I have a GPS android app that I have made. It uses a SQLite database on the SD card for storing the location data. I am trying make up an ERD (Entity–relationship diagrams) for the database. This is where I am having problems. The database has one master table for the tracks and one for the waypoint groups (a collection of one or more waypoints). These tables do not have the location data in them but just the name of the track or waypoint group, start/stop time and date, and a uid. For each row in these tables a new table is made that contains the latitude and longitude info. In the sub table each row is one point or vertex. And the sub table name is the uid of the "master" table plus "t_" or "w_" for traks or waypoints. This is what I came up with using https://www.draw.io:
http://s10.postimg.org/usqsrwjmx/Untitled_Diagram.png
(sorry I do not have the 10 rep points to post an image, lol)
I think that composition link between the tables is right as the sub table only exists if there is a row in the master table. If the master row is deleted the corresponding sub table is also deleted. But how to show that there is a sub table for every row in the master table? It is also a little weird because there is no need for a FK in the sub table as the table name provides this function.
I don't think that I want to change my database structure at this late date as the app is to be sent out for testing shortly, but I would be interested in other (superior) database designs for this problem.
In a relational database data is linked. In your database, however, not only data is linked but also data with table names. Thus you are mixing content with structure.
As far as I know you cannot display this in an ERD. You cannot implement this correctly in your dbms either (such that your dbms knows about the structure and helps you with appropriate constraints).
You are not using your RDBMS properly. So in spite of the late date: if I were in your place, I would change this into a proper relational database model.
EDIT: A proper relational model would simply be to have only one track_detail table with the track id in a column rather than in its name. Same for waypoint_detail with the master's waypoint id. No big change actually.
When I create a view I can base it on multiple columns from different tables.
When I want to create a lookup table I need information from one table, for example the foreign key of an order table, to get customer details from another table. I can create a view having parameters to make sure it will get all data that I need. I could also - from what I have been reading - make a lookup table. What is the difference in this case and when should I choose for a lookup table?? I hope this ain't a bad question, I'm not very into db's yet ;).
Creating a view gives you a "live" representation of the data as it is at the time of querying. This comes at the cost of higher load on the server, because it has to determine the values for every query.
This can be expensive, depending on table sizes, database implementations and the complexity of the view definition.
A lookup table on the other hand is usually filled "manually", i. e. not every query against it will cause an expensive operation to fetch values from multiple tables. Instead your program has to take care of updating the lookup table should the underlying data change.
Usually lookup tables lend themselves to things that change seldomly, but are read often. Views on the other hand - while more expensive to execute - are more current.
I think your usage of "Lookup Table" is slightly awry. In normal parlance a lookup table is a code or reference data table. It might consist of a CODE and a DESCRIPTION or a code expansion. The purpose of such tables is to provide a lsit of permitted values for restricted columns, things like CUSTOMER_TYPE or PRIORITY_CODE. This category of table is often referred to as "standing data" because it changes very rarely if at all. The value of defining this data in Lookup tables is that they can be used in foreign keys and to populate Dropdowns and Lists Of Values.
What you are describing is a slightly different scenario:
I need information from one table, for
example the foreign key of an order
table, to get customer details from
another table
Both these tables are application data tables. Customer and Order records are dynamic. Now it is obviously valid to retrieve additional data from the Customer table to display along side the Order data, and in that sense Customer is a "lookup table". More pertinently it is the parent table of Order, because it has the primary key referenced by the foreign key on Order.
By all means build a view to capture the joining logic between Order and Customer. Such views can be quite helpful when building an application that uses the same joined tables in several places.
Here's an example of a lookup table. We have a system that tracks Jurors, one of the tables is JurorStatus. This table contains all the valid StatusCodes for Jurors:
Code: Value
WS : Will Serve
PP : Postponed
EM : Excuse Military
IF : Ineligible Felon
This is a lookup table for the valid codes.
A view is like a query.
Read this tutorial and you may find helpful info when a lookup table is needed:
SQL: Creating a Lookup Table
Just learn to write sql queries to get exactly what you need. No need to create a view! Views are not good to use in many instances, especially if you start to base them on other views, when they will kill performance. Do not use views just as a shorthand for query writing.