I am building a webforms app using a 3 tier model and ado.net. (UI code behind) (middle tier 'classes') (DAL). Although EF would be a good fit, I would like to avoid it for this project as I am not familiar with it.
My database has a few tables and they have foreign key relationships between the tables. The app will have simple display, add, update, delete functions for each table.
I have created a class for each table that outlines the properties which correspond to each database column. So my question is how to handle the relationships between the tables, here is a simple example-
Table 'cars'
CarID
OwnerID
ColorID
Make
Model
Table 'Owners'
OwnerID
Fname
Lname
Table 'Colors'
ColorID
ColorName
On the Cars 'management' page -
The Owners and color tables should be represented as dropdownlists.
Do I load/bind the 'Owners' and 'Colors' lists with separate ado queries and simply save the 'IDs' of each field using the 'Cars' class or is there a way to tie these together, it seams there would be a more efficient way rather then making multiple database dips to pull the lists.
Any thoughts or comments welcome and appreciated.
Related
I’m developing an SQL database and want to separate out a few attributes of a Person table. These attributes will likely be updated or added to using CRUD operations themselves.
I’m having a hard time with something that might be simple and so I’m looking for some advice.
My Person model has basic stuff like name, email, phone etc. but also
Gender
Sexual orientation
Religion
Voice type
Person type
Experience level
And others like this these that would be best expressed an a select drop-down list in a form.
Currently I have fields in the Person table like
gender_id
sexual_orientation_id
etc…
Where this field is a relation to the ID field of those tables.
This is a
One Gender to Many Persons relationship
Wondering if this is a coherent way to structure the data. I’d like to keep these options in the database instead of a simple text array on the client for the form
The things that’s been hard for me is the amount of FK fields in the Person table. It’s seems off. I have like 10 of them for these select option sets.
Looking for some advice here. Thanks!!
Is it necessary to keep identity value of all those attributes in Person Table.
Like why do we need to have gender id in person where simply we can insert/update value from gender table at run time. It's not like in future someone is going to come and ask you to update couple of hundreds/thousand rows on basis of gender id , similar pattern can be seen for religion id , person type etc.
So in my opinion for values which are kind of universally unique such as gender, Religion, Sexual orientation you can keep value in person rather than foreign key relation.
if it can't be follow . so having 10 Foreign key in a table not a bad thing because here as per looking your requirement base tables have few rows, 10 foreign key will not be problematic even your table grow up to 100 GB .
I have lots of sql tables. The tables are "dependent" , i.e. constraints on foreign keys are defined between the tables.
I need to transfer the tables from sql to csv. What is correct way to do that:
Define tables exactly as they are defined in sql? (What should I do with the foreign keys?)
Try to generate other tables by joining the existing ones based on foreign keys in order to hide the foreign keys dependencies?
May be there are other options? What are the pros and cons ?
Thanks,
Note:This is need for another application that run some anylitics on the data
I would suggest to create a view in SQL which contains all information from all tables you need in your CSV later.
The view already implements the dependencies (link of two rows from different tables) and linkes all together in one table.
It would be way easier than your second proposal to create a new table because the view will do all the work for you.
I guess you will need your dependencies.
So you should not ignore them.
Here a quick example how they work:
Lets say you have 2 Tables the first one is named persons and the second one is cars. In the persons table you have 3 columns: ID, Name, Age. In the second one you have ID, Car. To see which person has which car you just check which id from the first table has which value for car in the second one.
If you link them together in a view the result is one single table with the columns ID, Person, Age, Car.
Same does the view.
Later you can simply export the view to CSV.
Maybe I can help you better if you define your needs a bit more detailed.
What kind of data is in your tables, how are they linked(what are the primary/secondary keys).
I have a website I develop that is structured a little like stackoverflow. I have a Posts table and a PostImages table in the database. The PostImages table looks like this:
PostImageId PK
PostId FK
Uri
MimeType
So posts can have lots of images associated with them.
I now have the requirement that other places on the site should have images: Users should be able to have images on their profile, Categories should be able to have images, and Addresses should be able to have images.
It seems best to only have a single Images table in my database. How should I model this? I could have a single table like this:
ImageId PK
PostId FK
CategoryId FK
AddressId FK
UserId FK
Uri
MimeType
I could have a single images table, then extra tables for each kind of object:
PostImageId PK FK
PostId FK
CategoryImageId PK FK
CategoryId FK
(where the PK of each item is also FK to an image from the Images table)
There are some other strategies, too: for instance, I could have a ___Images table for each type, and no shared Images table. I could have a many-to-many mapping table for each, and perhaps there are some other solutions I haven't thought of.
What is best? I don't know that much about database design - which will be the most flexible and easiest to use?
In real life projects, Database is designed regarding to the cost of accessibility of data. You mentioned two ways of designing your tables. Both are correct. If you put all your fields in one table there will be data redundancy. If you make two tables there is no problem.
But you have to keep in mind that joining two tables will cost more. So while fetching data from your server, this may make your page slow (If concurrently a lot of users try at the same time).
On the other hand, if you put it in one field, it will take more memory in database but less cost in data fetching. The choice is yours.
I went with the second choice. I have an Images table:
Images
ImageId PK
Name
Uri
Width
Height
MimeType
and several mapping tables:
PostImages
PostImageId PK FK
PostId FK
CategoryImages
CategoryImageId PK FK
CategoryId FK
I prefer this solution as I can add more mapping tables without changing the Images table. It's easier to maintain. Also, it allows the Images table to be more semantic as it only contains data about images.
The cost of the join isn't a big problem as I only return a small number of images in any query. However, I haven't tested the relative speed of the two methods.
I am trying to layout a database with multiple tables of a similar type. Consider a simplified veterinarian system. I have the following tables:
Dogs
Cats
Birds
Owners
My one constraint is that each Owner can have exactly 1 pet. I would like to keep referential integrity, but do not want to have my Owners table have three columns dedicated to foreign keys (seeing as I may need to add further pet species at some point).
Furthermore, when working with Entity Framework, I would like to have the entities setup to link as simple as Owner.Pet and have the underlying mechanisms handle deciding which table it needs to pull from.
I have come up with a way to do the second portion, but it is messy, at best. Has anyone tried something like this and had good luck coming up with a somewhat elegant solution?
For TPT inheritance, you'd make one table called Pet with an ID PK.
You'd then make a second table called Cat with a PK which is both a PK and a FK to Pet.
Having done this, you can now create a TPT model using these steps.
I would like to create a table called "NOTES". I was thinking this table would contain a "table_name" VARCHAR(100) which indicates what table put in the note, a "key" or multiple "key" columns representing the primary key values of the table that this note applies to and a "note" field VARCHAR(MAX). When other tables use this table they would supply THEIR primary key(s) and their "table_name" and get all the notes associated with the primary key(s) they supplied. The problem is that other tables might have 1, 2 or more PKs so I am looking for ideas on how I can design this...
What you're suggesting sounds a little convoluted to me. I would suggest something like this.
Notes
------
Id - PK
NoteTypeId - FK to NoteTypes.Id
NoteContent
NoteTypes
----------
Id - PK
Description - This could replace the "table_name" column you suggested
SomeOtherTable
--------------
Id - PK
...
Other Columns
...
NoteId - FK to Notes.Id
This would allow you to keep your data better normalized, but still get the relationships between data that you want. Note that this assumes a 1:1 relationship between rows in your other tables and Notes. If that relationship will be many to one, you'll need a cross table.
Have a look at this thread about database normalization
What is Normalisation (or Normalization)?
Additionally, you can check this resource to learn more about foreign keys
http://www.w3schools.com/sql/sql_foreignkey.asp
Instead of putting the other table name's and primary key's in this table, have the primary key of the NOTES table be NoteId. Create an FK in each other table that will make a note, and store the corresponding NoteId's in the other tables. Then you can simply join on NoteId from all of these other tables to the NOTES table.
As I understand your problem, you're attempting to "abstract" the auditing of multiple tables in a way that you might abstract a class in OOP.
While it's a great OOP design principle, it falls flat in databases for multiple reasons. Perhaps the largest single reason is that if you cannot envision it, neither will someone (even you) looking at it later have an easy time reassembling the data. Smaller that that though, is that while you tend to think of a table as a container and thus similar to an object, in reality they are implemented instances of this hypothetical container you are trying to put together and operate better if you treat them as such. By creating an audit table specific to a table or a subset of tables that share structural similarity and data similarity, you increase the performance of your database and you won't run in to strange trigger or select related issues later.
And you can't envision it not because you're not good at what you're doing, but rather, the structure is not conducive to database logging.
Instead, I would recommend that you create separate logging tables that manage the auditing of each table you want to audit or log. In fact, some fast google searches show many scripts already written to do much of this tasking for you: Example of one such search
You should create these individual tables and then if you want to be able to report on multiple table or even all tables at once, you can create a stored procedure (if you want to make queries based on criterion) or a view with an included SELECT statement that JOINs and/or UNIONs the tables you are interested in - in a fashion that makes sense to the report type. You'll still have to write new objects in to the view, but even with your original table design, you'd have to account for that.