Hot answers tagged

3

Metadata is data that describes your data. For example "Kenneth" is my name. It would be stored in a column called FirstName (for example). The metadata would be things like Variable length string with a max length of 50 First name of the user Last updated on Last updated by Analytics is more How many Kenneth's are there in the data. What is the ...


3

There is absolutely nothing wrong with joining on columns that are not PKs/FKs. If you are concerned about efficiency then the key is to have appropriate indexes defined to support the join operations you are using. Also, don't assume that the existence of a foreign key implies the existence of an index - some databases automatically create such an index but ...


3

Your 2 table design approach can be implemented using a view. This would not compromise your underlying database design based on 3 tables. Views are under used but often give the best of all worlds. Expanded: From your "normalised" 3 table design, which looks OK, you will CREATE VIEW (SELECT Employee ID, Language Name, Proficiency FROM Employee, ...


2

Most likely because the expression 1/10/1971 is interpreted as a numeric expression, i.e. 1 divided by 10 divided by 1971 which is 0 (with integer division rounding values down). Telling Access that this is a date can be done using quotes (not really recommended) or by using a date function, like this: IIf([DOB]<DateSerial(1971, 10, 1), "Mature", "Not ...


2

As mentioned in the comment by jkavalik constraints are there to enforce data integrity. While most modern optimizers can use the information in constraints to help make access decisions that is not their purpose. Here is a question you need to ask yourself - if the integrity of the data is not important - then how important is the data? If it is worth ...


2

Todd's answer is excellent. Here's an over simplified answer. There are pros and cons to normalization, beyond 1NF. The biggest pro to normalization is that it prevents mutually contradictory facts from being stored in a database. when the same fact is stored in more than one place, it becomes possible to store mutually contradictory versions of that ...


2

3 tables is best for the following reasons. You have a lookup table, pulling data from the lookup table is faster. You can Expand the employee table without worrying the effects on the language table You can Expand the language table without worrying the effects on the employee table. You can apply a two column key on the lookup table, making it ...


2

If I have understood what you need is: TASK TABLE: ID, NAME, DESCR and other attributes ROUTING TABLE: *ID, IDTASK, INFO and other attributes** ANALYSER TABLE: ID, IDROUTING and other attributes SUBCONTRACTOR TABLE: ID, IDROUTING and other attributes INTERNE USER TALBE: ID, IDROUTING and other attributes if you want to trace better the relations, you ...


1

I don't know much of T-SQL but I believe that to compare strings you need the logical operator AND. Try this: UPDATE StaffCopy SET StaffCopy.LastName=IIF(([LastName]='Avon' AND [FirstName]='Sarah'), 'Tyne', [LastName]);


1

Some clarifications: REFERENCES is the key word used for a FOREIGN KEY constraint (which allows to cascade DELETE or UPDATE). Your database design seems to have logical flaws. rating seems like a detail of the main table restaurant. Since you have a 1:1 relationship, you could just include the "rating" columns in the main table. If you need a separate ...


1

So, just to clarify: You want 1 Report to have Many Observations. The Observations then become either a Case or NoCase. Now, each case/nocase is linked by the ObservationID and the ReportID (or the Observation itself belongs to a ReportID), right? It wouldn't be a circle: Report->Observations->Case/NoCase (I can see the Case and NoCase entities as one ...


1

It is acceptable to have mutually exclusive attributes in a table. If you only have one pair of such attributes, this may be the most practical solution. However, some people may look at your situation as a sub-typing issue. In this view, you are missing the superset entity. You have a collection of (something), some of which are employees and some of ...


1

First of all, let me just say (as others have pointed out), that there is nothing wrong with having mutually-exclusive foreign keys! Second, despite it's elegance and applicability to other scenarios, I don't think the superset solution posted by @Joel Brown is appropriate for your exact case. Although it makes it much easier to deal with sub-types of ...


1

The best argument against the existing design is that there's really no good primary key on the table (except perhaps an identity column, which I don't consider a good primary key). That makes it hard to join to other tables. An advantage with your design is that a query can easily identify parcels where you (for instance) have mineral rights but not ...


1

First solution (3 tables) allow you to search of employees with given language in efficient and unambiguous way. The same language name is assigned to different employees (without literal errors like "english"/"Engliish"). It's a better way for developing new functionality in the future.


1

Your question is less about whether to use many-to-many relationships and more about the choice between a surrogate or natural key. You do need three tables - Employees, Languages and Employee_Languages - but you could choose to use the Language Name as a natural key instead of Language ID as a surrogate key. The choice of whether to use a natural or ...


1

As I said in my previous comment, you should have two main tables. Observation (the origin of all cases) Clinical_case (linked to an observation - note that "case" is an SQL keyword). It appears to me that you are overcomplicating things with so many tables. I think that any report made by a health professional should have the same status - be it a ...



Only top voted, non community-wiki answers of a minimum length are eligible