Could someone please help with information on a database

[RichUK]

what it is, is i work for company providing technical support for hardware mainly and software, there is a job opportunity for a 2nd line database admin (working as part of a team) mainly dealing with SQL, what i would like is for help on the following

1. what is a relational and none relational database?

2. can anyone provide any decent info/links with regards to SQL

i ask this is that it will help in my interview when applying for the job, the DBA team are prepared to take someone on with little experience with databases but experience with general second line tech support, as they have the time to train them up. (hopefully me)

i would be very grateful if anyone would be able to help in anyway possible..

many thanks,

RichUK

 

[mundane]

Link

 

[Gunslinger08]

A relational database is structured around a group of relationships between the tables in it. You define "keys" which uniquely identify rows in tables, and these can be used to relate one row of a table to a row of a different table. There are 3 main types of relationships. These are:

1 to 1: One element in a table can have exactly one element in another table. This would be like a person table related to a birth certificate table.

1 to many: One element in a table can have multiple (or zero) elements in another table. This would be like a parent table, with multiple children in a child table.

Many to many: Many elements can have multiple elements in another table, and they can all share the same elements in the other table. This should be avoided, because it can cause conflicts and anomalies when deleting, updating, and inserting into tables.

Non-relational databases are no longer used by modern IT professionals.

As for SQL: Pick up a book. It's really easy to learn, as there isn't a ton to it. You should find out whether they use SQL Server or Oracle (or another company's solution), as there are differences in the SQL statements used (though not huge). Also, SQL Server has several things that Oracle does not (including user defined functions and a well coded Enterprise Manager, which isn't based on Java).

 

[Seeruk]

You know on a side note...

I can't see a real need for there ever to be a one-one relationship. If the relationship is always one to one then why not bang em in the same table?

To use your example of people and birth cert's... why create a seperate table, thus requiring a query, in turn creating extra processing to pull information that can be sat with the original entity all along?

Just something I have wondered and in practice when creating databases have only ever needed to created relationships on a one to many basis.

 

[RichUK]

Originally posted by: joshsquall
A relational database is structured around a group of relationships between the tables in it. You define "keys" which uniquely identify rows in tables, and these can be used to relate one row of a table to a row of a different table. There are 3 main types of relationships. These are:

1 to 1: One element in a table can have exactly one element in another table. This would be like a person table related to a birth certificate table.

1 to many: One element in a table can have multiple (or zero) elements in another table. This would be like a parent table, with multiple children in a child table.

Many to many: Many elements can have multiple elements in another table, and they can all share the same elements in the other table. This should be avoided, because it can cause conflicts and anomalies when deleting, updating, and inserting into tables.

Non-relational databases are no longer used by modern IT professionals.

As for SQL: Pick up a book. It's really easy to learn, as there isn't a ton to it. You should find out whether they use SQL Server or Oracle (or another company's solution), as there are differences in the SQL statements used (though not huge). Also, SQL Server has several things that Oracle does not (including user defined functions and a well coded Enterprise Manager, which isn't based on Java).

thank you very much for your help, this was what i was looking for a snappy clear answer ... i have tried to google but i didnt really fully understand what i have read, and alot of the time it was giving me history .. stuff i didnt want to know

anyways thanks guys

 

[homercles337]

Originally posted by: Seeruk
You know on a side note...

I can't see a real need for there ever to be a one-one relationship. If the relationship is always one to one then why not bang em in the same table?

A little something called normalization.

 

[torpid]

Originally posted by: homercles337

Originally posted by: Seeruk
You know on a side note...

I can't see a real need for there ever to be a one-one relationship. If the relationship is always one to one then why not bang em in the same table?

A little something called normalization.

Aside from the more esoteric normal forms, sometimes the secondary table is "optional" information but still one to one. At least I think that it's still called one to one then.

In large tables that can help reduce wasted space that is allocated for frequently empty fields. That and some weird security scenarios are the only things I have seen one to one used for.

To the OP... if they are expecting any qualifications or experience, I can't imagine that you would be a good fit. If it's more like underling who will learn by example, maybe.

 

[RichUK]

i am a quick learner so it shouldn?t be a problem (i hope), a friend of mine works with SQL in another company and he told me that it is no biggy to learn, the job that i will be applying for is decent because i have the opportunity to learn the job (they are not looking for a know it all), but they are looking for someone with a good bases, in fact they do require some exp with SQL server 2000, but a friend of mine that works in that department said that it will not be over my head.

The reason i asked the questions is because my mate that works in that department, said "do you know what is a relational and none relational database is? and i replied no, he said that his boss guaranteed to ask the question in the interview.

I work on second line but in a different field, i am looking to move roles because of boardem so to speak "constantly on the phones" and sitting at the desk.. "we end up doing everything remotely" where as this new position allows me to speak to third party companies with regards to database support etc, and you get to visit and basically move around instead of just sitting at your desk

 

[torpid]

If the only thing they ask is do you know what a relational database and your job requires some experience with sql server, I'd be surprised.

Working in SQL or with SQL Server is not tough, but being a DBA is. At least being a good one...

 

[RichUK]

i wont start as a DBA even though that would be my title, although i will be given more responsibility as the time goes on "the support company i work for support about 250k users and the database team is not small, so i am lucky in that respect at being given the prospects to learn within a role ).

I would not imagine that would be the only question that he asks in the interview, its just my mate said that he would be guaranteed to ask that question (as he does in all of his interviews, so i thought i would try and research and make sure that i don?t look like a total newb when it comes to database's, i do have knowledge that i gained from college (within MS Access) and also producing a lot of diagrams (boring), although i didn?t major towards programming and databases etc, i took the networking root.

 

[Shazam]

Originally posted by: Seeruk
I can't see a real need for there ever to be a one-one relationship. If the relationship is always one to one then why not bang em in the same table?

Let's say you have a boat. You might want to keep cost info about the boat in one table, and physical info in another table. Both tables would have 1-1 relationships with the main boat table. As well, most RDBMS's have limits on how many bytes a single row can contain (SQL Server, for example, has a ~8k limit for each row), so practically speaking you might be forced into separating info into different tables.

 

[Seeruk]

Thx for the informative answers

I guess I just havent created anything massive enough to consitute such a need. Then again I work in content management mostly and its usually just a batch of keywords, and custom attributes. In all I have done if it can be kept in a single table then I've done so, and never had a performance issue even with ~10k users.

 

[DT4K]

Just another example of a one to one relationship.

We have a table that contains a record for each batch of material we create or use. There are several different types of materials. There is certain data that we need to store about all of these materials. But there is also a lot of type-specific data we need to store. We didn't want this table to have hundreds of fields, many of which would only be used for a small portion of the records.
So the main table has the common fields like MaterialID, Batch, ManufactureDate, Quantity, UOM, etc. Then we have another table for each of the material types that has the type-specific data and is linked one to one with the main table.