I have two columns in my Table called as Workers - Technicians. In Workers I have name of workers, and in Technicians I have name of technicians who is working in company. Here is how it looks:
Workers Technicians
Andy Kevin
Conan Jason
Jay Ray
Donald Daryl
Martin .
Mark .(rows goes on)
.
.(rows goes on)
What I want to do is to append these rows and having a column called Employees. Here what i want:
Employees
Andy
Conan
Jay
Donald
Martin
Mark
Kevin
Jason
Ray
Daryl
.
.
I don't want to create another table, I just want to add a new column. How would i do this?
An union statement should do the job here. Something like this:
select Name from Workers-Technitians where Worker not null
UNION
select Name from Workers-Technitians where Technitian not null
Keep in mind that both queries must have an equal column count when using an union
Assuming your table is named "staff", you could do something like this.
select distinct employees from (
select workers as employees from staff s1
union select technicians as employees from staff s2
) as emps
Perhaps you need to take another look at your design, though. Adding a third column won't work out for you because the first two columns represent two rows. In fact, there already appears to be a forced relationship between the workers and technicians-- they seem to be bundled together in the same record for no particular reason.
Consider starting fresh with an Employee table, with one employee per row, and abandon the existing table. You can maintain employee attributes in that table if the requirements are simple, or join a separate table of attributes for more complex cases. In either case, normalizing your data will make your life easier and use of a union to join columns will be unnecessary.
I also don't understand fully what you want to do (mainly because of this: if, say, a row has "Andy" in Workers and "Kevin" in Technicians, what will you put in Employees? Andy or Kevin?), but to add a new column to the table and then fill it with data you need to:
Add it (assuming your table is named Table and 100 chars are enough for the new column):
alter table [Table] add [Employees] nvarchar(100) null
Fill it:
update [Table] set [Employees] = [Workers]
-- or:
update [Table] set [Employees] = [Technicians]
I believe what you really want is a new table, Employees, and to change the Workers and Technicians into relationships drawn from it. For that, see the link Simon gave you about database normalization.
I don't entirely understand your question but you don't want to add an additional column, this introduces (more) data redundancy and will make any future updates or querying more difficult. Use one of the SELECT query solutions given and seriously consider re-factoring your two existing separate columns into a single column. I suggest you take a look at database normalisation if you're not already familiar with the concept.
Related
Lets say a have a table of employees:
ID
PERSON_NAME
PERSON_telephonenumber
1
JOHN
525323
2
NICK
624534
3
GEORGE
134355
4
BILL
676346
How can i update only the person_telephonenumber of nick and bill with new ones that i have been given from an excel file?And are much more than two values.
Please help!
Thank you in advance
First step is to make the Excel spreadsheet with two columns into an Oracle table with two columns; let's call them OLD_NUMBER and NEW_NUMBER. Let's call this table EXCEL_EXPORT. Also, you didn't tell us the data type of phone numbers; let's say it's varchar2(15).
How to import data from Excel to Oracle is a different question; I assume you do that already, so you know how. (The "how" depends on what you use to interact with the database; for example, I use SQL Developer, and it has very simple tools for this kind of process.)
Then, as an important step, make OLD_NUMBER primary key in the table:
alter table excel_export modify (old_number primary key);
This allows you to update the existing table through a join:
update
( select e.person_telephonenumber, ee.new_number
from employees e join excel_export ee
on e.person_telephonenumber = ee.old_number )
set person_telephonenumber = new_number
;
I don't know what is the best wording of the question, but I have a table that has 2 columns: ID and NAME.
when I delete a record from the table the related ID field deleted with it and then the sequence spoils.
take this example:
if I deleted row number 2, the sequence of ID column will be: 1,3,4
How to make it: 1,2,3
ID's are meant to be unique for a reason. Consider this scenario:
**Customers**
id value
1 John
2 Jackie
**Accounts**
id customer_id balance
1 1 $500
2 2 $1000
In the case of a relational database, say you were to delete "John" from the database. Now Jackie would take on the customer_id of 1. When Jackie goes in to check here balance, she will now show $500 short.
Granted, you could go through and update all of her other records, but A) this would be a massive pain in the ass. B) It would be very easy to make mistakes, especially in a large database.
Ids (primary keys in this case) are meant to be the rock that holds your relational database together, and you should always be able to rely on that value regardless of the table.
As JohnFx pointed out, should you want a value that shows the order of the user, consider using a built in function when querying.
In SQL Server identity columns are not guaranteed to be sequential. You can use the ROW_NUMBER function to generate a sequential list of ids when you query the data from the database:
SELECT
ROW_NUMBER() OVER (ORDER BY Id) AS SequentialId,
Id As UniqueId,
Name
FROM dbo.Details
If you want sequential numbers don't store them in the database. That is just a maintenance nightmare, and I really can't think of a very good reason you'd even want to bother.
Just generate them dynamically using tSQL's RowNumber function when you query the data.
The whole point of an Identity column is creating a reliable identifier that you can count on pointing to that row in the DB. If you shift them around you undermine the main reason you WANT an ID.
In a real world example, how would you feel if the IRS wanted to change your SSN every week so they could keep the Social Security Numbers sequential after people died off?
I have a single SQL table with columns Mary, Joe, Pat and Mick
I have rows of values for each persons weekly expenses
I want a single sproc to query a persons weekly expense value
i.e. a sproc that takes two variables #PersonsName and #WeekNumber and returns a single value
It wont work for me. It will work if I specify the persons name in the query but not if I pass the persons name to the query.
I'm pulling my hair out - is this something to do with Dynamic SQL?
Not sure if you are really digging into performance, scalability etc. as your scenario seems like a small personal tool. But still... as juergen suggested, you better design the schema in a different way. your current design won't scale easily if you want to add one more person to your database.
Instead, you can have something like
a persons table(person name, person Id)
an expenses table (week number, person id, expense)
This scales well. and with indexing on person id your queries can be faster
Suggestions apart,
Can I pass variable to select statement as column name in SQL Server seems to provide answer for your question
I may be total standard here, but I have a table with duplicate values across the records i.e. People and HairColour. What I need to do is create another table which contains all the distinct HairColour values in the Group of Person records.
i.e.
Name HairColour
--------------------
Sam Ginger
Julie Brown
Peter Brown
Caroline Blond
Andrew Blond
My Person feature view needs to list out the distinct HairColours:
HairColour Ginger
HairColour Brown
HairColour Blond
Against each of these Person feature rows I record the Recommended Products.
It is a bit weird from a Relational perspective, but there are reasons. I could build up the Person Feature"View as I add Person records using say an INSTEAD OF INSERT trigger on the View. But it gets messy. An alternative is just to have Person Feature as a View based on a SELECT DISTINCT of the Person table and then link Recommended Products to this. But I have no Primary Key on the Person Feature View since it is a SELECT DISTINCT View. I will not be updating this View. Also one would need to think about how to deal with the Person Recommendation records when a Person Feature record disappeared since since it is not based on a physical table.
Any thoughts on this please?
Edit
I have a table of People with duplicate values for HairColour across a number of records, e.g., more than one person has blond hair. I need to create a table or view that represents a distinct list of "HairColour" records as above. Against each of these "HairColour" records I need link another table called Product Recommendation. The main issue to start with is creating this distinct list of records. Should it be a table or could it be a View based on a SELECT DISTINCT query?
So Person >- HairColour (distinct Table or Distinct View) -< Product Recommendation.
If HairColour needs to be a table then I need to make sure it has the correct records in it every time a Person record is added. Obviously using a View would do this automatically, but I am unsure whether you can can hang another table off a View.
If I understand correctly, you need a table with a primary key that lists the distinct hair colors that are found in a different table.
CREATE TABLE Haircolour(
ID INT IDENTITY(1,1) NOT NULL,
Colour VARCHAR(50) NULL
CONSTRAINT [PK_Haircolour] PRIMARY KEY CLUSTERED (ID ASC))
Then insert your records. If this is querying a table called "Person" it will look like this:
INSERT INTO Haircolour (Colour) SELECT DISTINCT HairColour FROM Person
Does this do what you are looking for?
UPDATE:
Your most recent Edit shows that you are looking for a many-to-many relationship between the Person and ProductRecommendation tables, with the HairColour table functioning as a cross reference table.
As ErikE points out, this is a good opportunity to normalize your data.
Create the HairColour table as described above.
Populate it from whatever source you like, for example the insert statement above.
Modify both the Person and the ProductRecommendation tables to include a HairColourID field, which is an integer foreign key that points to the PK field of the HairColour table.
Update Person.HairColourID to point to the color mentioned in the Person.HairColour column.
Drop the Person.HairColour column.
This involves giving up the ability to put free form new color names into the Person table. Any new colors must now be added to the HairColour table; those are the only colors that are available.
The foreign key constraint enforces the list of available colors. This is a good thing. Referential integrity keeps your data clean and prevents a lot of unexpected errors.
You can now confidently build your ProductRecommendation table on a data structure that will carry some weight.
Are you simply looking for a View of distinct hair colors?
CREATE VIEW YourViewName AS
SELECT DISTINCT HairColour
FROM YourTableName
You can query this view like a table:
SELECT 'HairColour: ' + HairColour
FROM YourViewName
If you are trying to create a new (temp) table, the syntax would look like:
SELECT Name, HairColour
INTO #Temp
FROM YourTableName
GROUP BY Name, HairColour
Here the GROUP BY is doing the same work that a DISTINCT keyword would do in the select list. This will create a temp table with unique combinations of "Name" and "HairColour".
You need to clear up a few things in your post (or in your mind) first:
1) What are the objectives? Forget about tables and views and whatever. Phrase your objectives as an ordinary person would. For example, from what I could gather from your post:
"My objective is to have a list of recommended products based on each person's hair colour."
2) Once you have that, check what data you have. I assume you have a "Persons" table, with the columns "Name" and "HairColour". You check your data and ask yourself: "Do I need any more data to reach my objective?" Based on your post I say yes: you also need a "matching" between hair colours and product ids. This must be provided, or programmed by you. There is no automatic method of saying for example "brown means products X,Y,Z.
3) After you have all the needed data, you can ask: Can I perform a query that will return a close approximation of my objective?
See for example this fiddle:
http://sqlfiddle.com/#!2/fda0d6/1
I have also defined your "Select distinct" view, but I fail to see where it will be used. Your objectives (as defined in your post) do not make this clear. If you provide a thorough list in Recommended_Products_HairColour you do not need a distinct view. The JOIN operation takes care of your "missing colors" (namely "Green" in my example)
4) When you have the query, you can follow up with: Do I need it in a different format? Is this a job for the query or the application? etc. But that's a different question I think.
I am hopping on a project that sits on top of a Sql Server 2008 DB with what seems like an inefficient schema to me. However, I'm not an expert at anything SQL, so I am seeking for guidance.
In general, the schema has tables like this:
ID | A | B
ID is a unique identifier
A contains text, such as animal names. There's very little variety; maybe 3-4 different values in thousands of rows. This could vary with time, but still a small set.
B is one of two options, but stored as text. The set is finite.
My questions are as follows:
Should I create another table for names contained in A, with an ID and a value, and set the ID as the primary key? Or should I just put an index on that column in my table? Right now, to get a list of A's, it does "select distinct(a) from table" which seems inefficient to me.
The table has a multitude of columns for properties of A. It could be like: Color, Age, Weight, etc. I would think that this is better suited in a separate table with: ID, AnimalID, Property, Value. Each property is unique to the animal, so I'm not sure how this schema could enforce this (the current schema implies this as it's a column, so you can only have one value for each property).
Right now the DB is easily readable by a human, but its size is growing fast and I feel like the design is inefficient. There currently is not index at all anywhere. As I said I'm not a pro, but will read more on the subject. The goal is to have a fast system. Thanks for your advice!
This sounds like a database that might represent a veterinary clinic.
If the table you describe represents the various patients (animals) that come to the clinic, then having properties specific to them are probably best on the primary table. But, as you say column "A" contains a species name, it might be worthwhile to link that to a secondary table to save on the redundancy of storing those names:
For example:
Patients
--------
ID Name SpeciesID Color DOB Weight
1 Spot 1 Black/White 2008-01-01 20
Species
-------
ID Species
1 Cocker Spaniel
If your main table should be instead grouped by customer or owner, then you may want to add an Animals table and link it:
Customers
---------
ID Name
1 John Q. Sample
Animals
-------
ID CustomerID SpeciesID Name Color DOB Weight
1 1 1 Spot Black/White 2008-01-01 20
...
As for your original column B, consider converting it to a boolean (BIT) if you only need to store two states. Barring that, consider CHAR to store a fixed number of characters.
Like most things, it depends.
By having the animal names directly in the table, it makes your reporting queries more efficient by removing the need for many joins.
Going with something like 3rd normal form (having an ID/Name table for the animals) makes you database smaller, but requires more joins for reporting.
Either way, make sure to add some indexes.