Tag Info

Hot answers tagged

6

Option B is the worst choice: Why Because by keeping values in CSV format in a single column, you are violating first NF http://en.wikipedia.org/wiki/First_normal_form. Most critical drawback of violation of first NF is complex join conditions. You have to apply join using LIKE operators and worst wildcard options or using other string functions. ...


4

Option B is a bad choice and to answer you question on performace. Perfomance wise option A is better choice. Option A will have simple query where as option B need to run complex sql query. Option A offers better indexing options which in turn offers better performance. Option A is neat and clean design.


4

Size is one consideration. An int can hold up to -2,147,483,648 in four bytes. A char will need 11 bytes to hold the same value. There are built-in functions to manipulate the various data types. DATEADD() and DATEDIFF() are two examples. This will not be possible with date-stored-as-text. Constantly CASTing back and forth will not make for efficient ...


4

Your colleague is correct that it is easier to simply not think about it and just store everything as a varchar. But this comes at a large cost in terms of space requirements, performance, flexibility in querying data, and most importantly, lack of data integrity. This is not just a one-time cost; it is paid repeatedly over the lifecycle of the ...


3

There are several situations in which it's better to represent numbers using some kind of numeric data-type. It's a little more efficient, but that's just the beginning. You get support for built-in arithmetic using SQL operators without performing type conversions at run time. Not only do type conversions slow things down, but they can result in numerous ...


2

This is likely to be a many to many relationship. create table drivers ( driver_id int primary key, ... ); create table trucks ( truck_id int primary key, ... ); create table drivers_trucks ( driver_id int references drivers(driver_id), truck_id int references trucks(truck_id), primary key (driver_id, truck_id) );


1

From a purely performance standpoint, using the identity key as a clustered primary key will be most efficient. From there I would do a non clustered key with a unique constraint on datetime, patientid.


1

Swap the foreign key so that the Drivers table has id_truck. This way multiple drivers can be associated with the same truck.


1

Questions to ask could include: What fits well with your current skills? (That might make it 'easier' to use.) Is your focus on getting something working soon, or on developing new skills? What is the cost of your choices (money, time, effort, unfamiliarity, etc)? With your list you do emphasize cost as a factor and the database is not expected to be ...


1

Zip codes should be stored as text, as some start with 0 (screwing up formatting/sorting) and there is no reason to do math on them. Also, if you want to store global postal codes, they often contain letters. Phone numbers are a maybe for text, especially if there might be extensions. Or you want to store numbers like 1-800-GOT-JUNK. There's no reason to do ...


1

First - stop using the phrase "Null value", it will just lead you astray. Instead, use the phrase "null marker" - a marker in a column indicating that the actual value in this column is either missing or inapplicable (but note that the marker does not say which of those options is actually the caseĀ¹). Now, imagine the following (where the database does not ...


1

I think if you look at your model and you consider the requirements that it doesn't handle (i.e. your questions) then you will find that you need to expand your model somewhat. Consider the following ERD: (Note I use the James Martin crows foot notation which is a little more compact than what you have used but should be pretty simple to understand. The ...



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