If i have bills (from vendors), and invoices (to customers), would it be better to keep them separate (in two tables), or in a single table?
What about vendors / customers?
These are all relational-inheritance problems, can you give me some best practices regarding this?
It seems to me that an incoming bill and an outgoing invoice are really different things:
The outgoing invoice will have line items that match your product table
The incoming bill will have a very formal approval process, involving managers, finance, and accountants
The "From" on an incoming bill is your partner, but on an invoice, the partner's name is the "To"
Entities that are that different should have their own table. If they have common properties, you could store them in a Document table, and create a relation between that table and the Invoice and Bill table.
I would suggest that if they are separate concepts, keep them separate. Usually when you start out designing a database and you have entities that have the same columns in their tables, the urge arises to consolidate them into 1 table. If you know for a fact that for the duration of the solution, you will never need ta add say customer-specific fields or vendor-specific fields, I would say go ahead and make them 1 table.
Keeping them separate allows each entity to develop on its own as the system grows and matures.
A dangerous road for many reasons.
I suppose logically speaking you could collapse everything into one table with a column "PrimaryKey" and optional columns Col1, Col2, Col3, etc. all varchars interpretable to other types.
Especially with financial data where there are audit trail and archiving issues, this is not a simplification.
(But it's the sort of strategy we all go through as a passing phase ...:) )
In our ERP system we have bills and invoices separate; vendors and customer we have in one table.
Related
When I write C# applications, I use to write sql relations as inner join for example, in the query:
select xxx from TableA as A inner join TableB...
I don't really see why I should define these realtions (hard defined) in Management Studio.
Should I, and why if required?
Regards
Two main reasons and a minor third one: data-integrity and performance - and documentation.
Performance is simple: if you define a relationship between two tables you will normally automatically create an index on those two columns, and your database will use those indexes to speed up look-ups when they can be used.
As for data-integrity, even though you leave the important part of your join out of your example, you assume in a join that a foreign key field can only contain values that exist in the primary key field. Your database can make sure of that, and will make sure of that when you define those relations in SQL server.
If you do not define those relationships, you could easily create a situation where you have, say, Orders, that belong to Customer 12345, who does not exist in your Customer table.
Or you could delete Customer 23456, leaving all their Orders in your system, but without an existing Customer.
A final reason is documentation: your database is not only made to be accessed by your code. If someone else accesses your database and sees only unconnected unrelated tables, how will they know that field cstID in table CstOrderHdr happens to be a reference to field id in table Relations where Relation.RelTyp = 'Customer'? Who is to stop them from filling in 0, null or a random number?
I'm trying to design a snackbar automation system (to answer the first question - No, it's not a homework, it's for learning purposes) and I have an issue with with the recipes and how to present them in the database. I have two options:
Option 1:
[Ingredients] -> [IngrID, IngrName]
[Recipe] -> [RecipeID, RecipeName]
[IngRecipe] -> [IngrID, RecipeID]
In this case the third table is a typical many-to-many table, the model looks correct and it's a piece of cake to manipulate with the data using Entity Framework. But I want to keep track of the amounts as well. Generally I use Ingredients as a table to insert the new purcheses. If the ingredient exist, just update the amount.
Option 2
Now if I add column "amount" as a column to IngRecipe, the whole idea of many-to-many table vanishes and I no longer can use the entity model to fill the fields automatically. But I can't seem to find a more apropriete place for this column. Where and how will I say "Well, get me 100 gr of chicken breast and add it to whatever recipe"
Any help is appreciated. Thanks in advance!
It's a solid model start, consider:
RecipieIngredients -> Recipe (FK), Ingredient (FK), IngredientQuantity
Key over (Recipe, Ingredient)
Note that it is still a M-M relationship (the quantity is not part of the PK nor involved in a FK), just with more relevant data for this relationship pair. The names can be changed, but at some point, this must be represented as a M-M relationship in a normalized relational model.
Don't let the framework ruin a good normalized design - and I hope EF can cope with such trivial scenarios; even LINQ2SQL can.
Initially, I'm thinking of one table that will handle all the audit logs but in terms of flexibility, like for example in the future do you think, it will make sense to break the table and have each application to have their own audit log table?
Like for example, for reservation, I'll have one audit table that will track all the changes on the field level, and then I'll have another audit table for visa application.
My current audit log table design is like this
AuditLogID
Module
ActivityType
ReferenceNumber
FieldName
OldValue
NewValue
IPAddress
The pattern you are describing seems to be along the lines of Entity Attribute Value (EAV), which is one row per field.
Assuming that all field changes to all tables in all of your modules will result in a new audit row, there are some potential issues with this approach
the audit table will get very huge
the number of writes will be large and frequent and could negatively impact performance - correct clustering of this audit table will be important
in order to view / compare rows, you will need to reassemble fields back into rows in order to be meaningful to a user
You are also potentially missing out on 2 important attributes to audit, viz UserId and TimeStamp of the change
There is probably some normalisation you can do to your audit tables, e.g. Have a 'one per row' audit table and a 'one per field' audit table.
e.g. IP Address, ReferenceNumber, Activity Type, UserId and TimeStamp are probably a constant for all updated fields in the same row which were changed by the single 'action' and belong at once per row.
There are also other alternatives
One Audit table per Live table, which is generally a clone of the fields, plus a TimeStamp field and a new Primary Key (or just leave it as a heap)
SQL Change Data Capture
SQL Server 2008 change data capture vs triggers in audit trail
If all changes occur from the same App, you can use a Document Store
(e.g. store the rows as Xml, Blobs or other Metadata), keeping
serialized versions of the change in a single row, and possibly just
exposing a couple of indexable fields (Column Name, Date) for query
purposes.
If you choose the Document store approach, you might also
choose not to store audit data in a RDBMS at all. NoSQL stores like
RavenDB or MongoDB are good at storing high volumes
I got site for selling products. In my database I have 3 tables: Users, Countries, Products.
Each user can sale his products in many countries.
When clients come to visit, my site, they can choose to search for product by country and by product price( same product sold by same user can have different prices in each country).
I thought about two implementations for this:
Create a linked table with user_id, country_id, product_id. In this case each time I would like to add new product I will need to update two tables, the linked table and the products table.
Or create new table for each country, that will have products in it. So when I will have to add new product I will only need to update one table.
I like my second solution more, because I think it will perform faster, for both reading and inserting, how ever it's management is hard, I will have lots of tables, and what if instead of counties I would like to use cities, I will get thousandths of tables.
Is there a way in MySQL to create a table of tables?
What do you think about my design will it rarely perform faster?
Do NOT go for the second solution. Relational databases are meant to have a fixed number of tables, and you will run into a lot of problems if you try to have a variable amount of tables in the manner you describe.
If I understood your requirements correctly, you should probably use two linked tables: one that contains user_id and country_id (thus telling where each user may sell products), and one that contains country_id, product_id, and price (thus telling the price of each product in each country). (This assumes that a product costs the same within a country no matter who sells it.)
I have a medical database that keeps different types of data on patients: examinations, lab results, x-rays... each type of record exists in a separate table. I need to present this data on one table to show the patient's history with a particular clinic.
My question: what is the best way to do it? Should I do a SELECT from each table where the patient ID matches, order them by date, and then keep them in some artificial list-like structure (ordered by date)? Or is there a better way of doing this?
I'm using WPF and SQL Server 2008 for this app.
As others have said, JOIN is the way you'd normally do this. However, if there are multiple rows in one table for a patient then there's a chance you'll get data in some columns repeated across multiple rows, which often you don't want. In that case it's sometimes easier to use UNION or UNION ALL.
Let's say you have two tables, examinations and xrays, each with a PatientID, a Date and some extra details. You could combine them like this:
SELECT PatientID, ExamDate [Date], ExamResults [Details]
FROM examinations
WHERE PatientID = #patient
UNION ALL
SELECT PatientID, XrayDate [Date], XrayComments [Details]
FROM xrays
WHERE PatientID = #patient
Now you have one big result set with PatientID, Date and Details columns. I've found this handy for "merging" multiple tables with similar, but not identical, data.
If this is something you're going to be doing often, I'd be tempted to create a denormalized view on all of patient data (join the appropriate tables) and index the appropriate column(s) in the view. Then use the appropriate method (stored procedure, etc) to retrieve the data for a passed-in patientID.
Use a JOIN to get data from several tables.
You can use a join (can't remember which type exactly) to get all the records from each table for a specific patient. The way this works depends on your database design.
I'd do it with separate SELECT statements, since a simple JOIN probably won't do due to the fact that some tables might have more than 1 row for the patient.
So I would retrieve multiple result-sets in a simple DataSet, add a DalaRelation, cache the object and query it down the line (by date, by exam type, subsets, ...)
The main point is that you have all the data handy, even cached if needed, in a structure which is easily queried and filtered.