Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
kelly
Starting Member
6 Posts |
Posted - 2005-08-04 : 08:51:38
|
| I've been using databases for twenty years now and have just started using SQL Server 2000. I've used dbase III+, FoxPro and FileMaker Pro mostly and have a pretty good generally knowledge of databases. However, I'm constantly scratching my head over a few SQL Server foundational issues and would appreciate some help.Probably the biggest question is this:In FileMaker Pro (and FoxPro if I remember correctly), I would set the relationship once and then never have to think about it much again. Then I could create virtual tables and sub forms which contained data from several tables and view/update them with ease. However, in SQL Server I've noticed that while I can define the relationships in a database diagram, every query has to recreate the joines. If I try to use a view I can only update one table at a time which seesm whacky to me. So what on earth is the point of having relationships if you have to redefine them with each query? I've read that referrential integrity is the reason but that only baffles me further as I don't understand the point. Sure I get cascading deletes but there has to be more to the feature than that.Also, when I want to insert data in multiple related tables I'm used to utilizing the existing relationship, mentioning the primary key once and then simply filling in the data. It seems in SQL Server that I have to also insert on the foreign key. This doesn't make sense as the database should know which record I'm talking about in the foreign key table(s) as they're related. Again though, I'm not only recreating the relationship in the insert but I'm also having to specify the foreign key. I guess it just makes me wonder why it's not simply checking the relationships which already exist.So I'm a bit baffled and any help would be most appreciated.Thanks in advance!Kelly |
|
|
JimL
SQL Slinging Yak Ranger
1537 Posts |
Posted - 2005-08-04 : 10:10:02
|
| Your Used to systems that for all sense and purposes deal with one record at a time. SQL is set based and can update or retrieve data much faster then those systems. But because of this you need to indicate the table relationships on each View and SP. (Note: I would concentrate on learning Stored Procedures they are your most powerful SQL tool).The advantage to this is you are not locked into the base relationship and can alter it from procedure to procedure. Ok now the next bit I say with tongue in cheek.One easy way to get started is to use Access 2002 or later .adp. Once established Access will remember the Basic SQL table relationships for you and give you a GUI tool to create your simple Procedures without worrying about syntax errors. It is not a substitute for good programming skills and cannot handle the complex code that makes SQL Stored procedures so powerful but it will get your feet wet and is a good tool to quickly make simple procedures.JimUsers <> Logic |
 |
|
|
Kristen
Test
22859 Posts |
Posted - 2005-08-04 : 10:47:28
|
Hi kelly, Welcome to SQL Team!Yup, I'm with you on that. I'm a database person, so I work with JOINs and FKs and stuff all the time.However, we have built our own "Application Engine" will leverages that information for the application developers.So, they make a Form with an Address on it. They place the Address_Country_Code column on the form and it says "That's got a Foreign Key to Country_Code_Lookup table, so here we go with a picklist".Then they want to use the Owners_Name, each Address has only one Owner, so it says "That will be the one that JOINs to the Address table - because there is no other relationship available" and again, away they go.But that's all the job of the application tools, and not the database.We used a report writer once ... Business Objects maybe? ... that provided the tables in a tree. Open up the Address table and then you could "open up" the Address_Country_Code column and see all the columns in the Country_Code_Lookup table - pick one of those and it would add a JOIN to the SQL generated for a report.Probably SQL's own Report Services does this too, I've not used it.But if you want to write raw SQL none of that is going to help much!(Actually, it can. I have a little SProc called KLC [Kristen's List Columns ] that lists all the columns, joins, and other stuff so I can cut and paste from it. It uses the Foreign Key definitions in SQL Server to do that. (Can't post the code here I'm afraid because it uses a whole raft of our tables that overload SQL's internal data definitions) so I just type "KLC MyTable" and cut and paste the bits I want for the job at hand)Kristen |
 |
|
|
ajthepoolman
Constraint Violating Yak Guru
384 Posts |
Posted - 2005-08-05 : 09:53:34
|
| Cheater!Actually I guess that I am guilty of something similar as well. Our in house application was built using homegrown SQL wizards that take the name of an existing table and create all the stored procedures and the Visual Basic forms that will interact with that table. It is really cool to have a new chunk of functionality ready for a build and the testing department within an hour. Aj--What happens when social workers and programmers collide:Social Worker: "They aren't an Identified Resource Family, they are an IR Family."Me: "What does IR stand for?"Social Worker: "Identified Resource." |
 |
|
|
Kristen
Test
22859 Posts |
Posted - 2005-08-05 : 10:06:49
|
Cheats 'R' Us Yup, we do the same. 1) Create a table (in EM Designer, but we script it and run the script)2) Run SProc to import the revised DB structure into our internal tables3) Run Sproc to Generate the standard "Get, Delete & Save SProcs and Standard Trigger"4) In our Application [dev tools] click "Generate standard forms" for TableX5a) Choose which columns to use for selection criteria, and whether Wildcard, Exact match or Range5b) Choose the columns for the "Results List"5c) Adjust the selected columns from the maintenance Form (maybe not all columns required)5d) Forms code generated, and SProcs for the "Find"6) Play with the "Find" form, the "Results list" and the "Record Maintenance form" Now change the structure of the database - bit wider on ColumnX, rename ColumnY 'coz the original name was Dumb!. And in our Admin Tools change the properties of the column (Force CAPs, Set minimum length, change the "Prompt" Legend for the data and so on)And all the forms etc. change dynamically!I can't imagine all this hard work programming that folks doMake an new ASP page to edit a record? Why? Kristen |
 |
|
|
kelly
Starting Member
6 Posts |
Posted - 2005-08-07 : 01:56:03
|
| Thanks everyone for the info -- especially your post Jim.While cheating is nice, it doesn't help me much in this instance as the cheats are not publicly available.That said, I have a few other thoughts and comments.Jim, years ago someone told me that Microsoft Access couldn't be used as a front end to SQL server. I then discovered Access Projects and taught a few young developers that they don't always know everything <snicker!>. However, I only own Access 2000 which I've discovered is not fully compatible with SQL Server 2000. Nice going MS! Anyway, your post revived that idea in me and I'd like to hear some more feedback from anyone using Access 2002 (or later) as a front end to SQL Server.I'm not sure why you stated that your advice on Access was "tongue in cheek" -- can you explain this?Based on reading over some of your posts I figured I'd better give you all a bit more information.I'm using SQL Server as a backend database for a directory based web site which we've had for ten years. I wrote the first version in 1995 in static html, the second version in 1997 completely in Perl with a dbm backend and in 2002 we bought an off the shelf asp frontend/MS SQL backend directory software system to give us a head start. We have since modified the system so completely that it's no longer near what it was. However, there are times in which it's a house of cards and I'm slowly moving all the intensive database work from asp scripts into stored procedures. So for those of you who recommended stored procedures, got it, love them, writing more.All that said, there are two remaining issues:1. asp sucks as a front end for my own forms, updating, and reporting which is why I'm wondering about using Access and would appreciate any and all feedback.2. My original question still begs for an answer. Meaning, if we're redefining the joins in each stored procedure, what's the point of the database diagrams feature in MS SQL other than drawing pretty pictures of your schema. I have a sneaky suspicion that it does more but that I haven't figure out how to tie into this. For instance, one of the options is "Enforce relationship for INSERT'S AND UPDATES." That would "seem" like a pretty important and powerful feature but I'm at a loss as how this all ties together.As always, any information is most appreciated.Kelly |
 |
|
|
Kristen
Test
22859 Posts |
Posted - 2005-08-07 : 06:16:37
|
"as the cheats are not publicly available"Yeah, sorry about that! Wish I could help you with that one, but we consider our Cheats give us market-advantage, so I don't teckon they will be available any time soon!"asp sucks as a front end for my own forms"Why? Web pages too slow? or interface not "rich enough"? or something else maybe?"reporting"Have you looked at Report Services for SQL? (There's a forum here if you need any advice) - I know nothing about it, but it seems to have got a good press - and deployment is easy, users just need a browser!"what's the point of the database diagrams feature"You can change your database structure from there too (its an Edit tool, as well as a Reporting tool).But, yeah, its basically a pretty picture. For newbies arriving at an unknown database that's pretty handy. But we don't have one on our applications ..."Enforce relationship for INSERT'S AND UPDATES"That's basically getting the database to do some additional tasks once you have got Foreign Keys in place.So you have an address table, and a customer table. Each customer can have more than one address. Lets assume that you have a Code for each customer (e.g. "SMITH01" rather than an Identity number)Do you want to change the code for "SMITH01" to "JONES01" - perhaps she got married!What happens to the address? Worse - SQL won't let you do this:BEGIN TRANSACTIONUPDATE ADDRESS Change SMITH to JONESUPDATE CUSTOMER Change SMITH to JONESCOMMITbecause the JONES record does not exist when trying to change the ADDRESS. ... and you can't swop the order because changing the Customer table would "orphan" the ADDRESS records.You can turn off the checking on FKs, but that will let the database generate orphan records, which doesn't seem like a good idea! and you can set up Cascades for Update and/or Deletes. This is a bit of a winner - Now you can change SMIT01 to JONES01 on the Customer record and it will update the corresponding code field in the Address too - and you can delete the SMIT01 Customer record and the corresponding Address records will be deleted too.Here's a code same to illustrate it:SET NOCOUNT ONGODROP TABLE ADDRESSGODROP TABLE CUSTOMERGOCREATE TABLE CUSTOMER( cust_Code varchar(10) NOT NULL, cust_Name varchar(30) NOT NULL, PRIMARY KEY ( cust_Code ))GOCREATE TABLE ADDRESS( adr_cust_Code varchar(10) NOT NULL, adr_ID int identity(1,1) NOT NULL, adr_Address varchar(1000) NOT NULL, PRIMARY KEY ( adr_cust_Code, adr_ID ))GOINSERT INTO CUSTOMERSELECT 'SMIT01', 'Smith'GOINSERT INTO ADDRESSSELECT 'SMIT01', 'Smith Address Here'GOALTER TABLE ADDRESS ADD CONSTRAINT FK_ADDRESS_CUSTOMER FOREIGN KEY ( adr_cust_Code ) REFERENCES CUSTOMER ( cust_Code )GOPRINT ''PRINT 'Attempt to update Customer without Address'PRINT ''GO-- This is not allows!UPDATE USET cust_Code = 'JONE01'FROM CUSTOMER UWHERE cust_Code = 'SMIT01'GOPRINT ''PRINT 'Try with transaction block'PRINT ''-- This won't work eitherBEGIN TRANSACTIONUPDATE USET cust_Code = 'JONE01'FROM CUSTOMER UWHERE cust_Code = 'SMIT01'UPDATE USET adr_cust_Code = 'JONE01'FROM ADDRESS UWHERE adr_cust_Code = 'SMIT01'COMMITGOPRINT ''PRINT '------------------------------------------'PRINT ''GOPRINT 'Remove the CHECK on the FK'PRINT ''GOALTER TABLE ADDRESS NOCHECK CONSTRAINT FK_ADDRESS_CUSTOMERGO-- This will work, but allows orphans to be createdUPDATE USET cust_Code = 'JONE01'FROM CUSTOMER UWHERE cust_Code = 'SMIT01'GOPRINT ''PRINT 'Data now has orphan address'PRINT ''GOSELECT * FROM CUSTOMERSELECT * FROM ADDRESSGO-- Restore the original dataUPDATE USET cust_Code = 'SMIT01'FROM CUSTOMER UWHERE cust_Code = 'JONE01'GOPRINT ''PRINT 'Create Cascade FK'PRINT ''GOALTER TABLE ADDRESS DROP CONSTRAINT FK_ADDRESS_CUSTOMERGOALTER TABLE ADDRESS WITH NOCHECK ADD CONSTRAINT FK_ADDRESS_CUSTOMER FOREIGN KEY ( adr_cust_Code ) REFERENCES CUSTOMER ( cust_Code ) ON UPDATE CASCADE ON DELETE CASCADE GOPRINT ''PRINT ''PRINT '"Before" Data [Cascade is active]'PRINT ''SELECT * FROM CUSTOMERSELECT * FROM ADDRESSGOUPDATE USET cust_Code = 'JONE01'FROM CUSTOMER UWHERE cust_Code = 'SMIT01'GOPRINT ''PRINT '"After" Data'PRINT ''SELECT * FROM CUSTOMERSELECT * FROM ADDRESSGOPRINT ''PRINT 'Delete customer [Cascade is active]'PRINT ''DELETE DFROM CUSTOMER DWHERE cust_Code = 'JONE01'GOSELECT * FROM CUSTOMERSELECT * FROM ADDRESSGOSET NOCOUNT OFFGO Kristen |
 |
|
|
elwoos
Master Smack Fu Yak Hacker
2052 Posts |
Posted - 2005-08-08 : 03:48:10
|
| Hi KellyWe use SQL server as a back end to an Access (97!!!!) interface i.e. we don't use adp. Personally I hate it because of the sercurity issues that we have (some down to poor design from the supplier) and so we are looking at ASP as a replacement for all the Access parts and for our reporting which is currently in a seperate (and even worse) Access database.Don't know if this helpssteveAlright Brain, you don't like me, and I don't like you. But lets just do this, and I can get back to killing you with beer. |
 |
|
|
|
|
|
|
|