From fuller.artful at gmail.com Mon Mar 10 07:43:16 2014 From: fuller.artful at gmail.com (Arthur Fuller) Date: Mon, 10 Mar 2014 08:43:16 -0400 Subject: [dba-SQLServer] PK/ANPK Debate Message-ID: To start off the week, I thought that I would re-open the PK/ANPK debate, limiting the discussion to a specific group of tables: lookup tables. Consider this example: SCENARIO 1: Table: Volunteers PK: VolunteerID (autonumber) Columns: Name, Address, etc. Table: Languages PK: LanguageID (autonumber) Columns: Language(varchar(20) Associative Table: VolunteerLanguages PK: VolunteerID, LanguageID Columns: VolunteerID, LanguageID, and perhaps Profiency SCENARIO 2: Table: Volunteers PK: VolunteerID (autonumber) Columns: Name, Address, etc. Table: Languages PK: Language Columns: Language(varchar(20) Associative Table: VolunteerLanguages PK: VolunteerID, Language Columns: VolunteerID(int), Language(varchar(20), and perhaps Profiency Both scenarios exist to allow the recording of multi-lingual Volunteers. The knee-jerk choice is to go with the first scenario, but I am calling this into question, on the grounds that it complicates queries, comboBoxes etc. unnecessarily. The name of the language is sufficient as a PK in itself. No one wants duplicate occurrences of any language name in this table. In the associative table, the second Scenario takes up a little more space. But surely in this age when laptops have multi-TB hard disks, this is of no real concern. So why complicate queries, combos, listboxes etc. with a pointless lookup and additional Join? The same argument could be applied to many lookup tables, for example Countries? Why bother with an ANPK when the official ISO abbreviations exist, are easily obtained, and are universally recognized? Perhaps the argument is even stronger here, since the ISO codes are char(3)? In case it isn't clear, I am not arguing for this design in the common Customer+Orders+OrderItems situation, but only in the subset of tables where there are a small number of rows whose text values must be unique. In the past, I have designed this subset according to the first scenario, Scenario 1 demands either a unique index on the text column or logic in the front end to achieve the same thing. In short, I no longer see the point. -- Arthur From gustav at cactus.dk Mon Mar 10 08:19:31 2014 From: gustav at cactus.dk (Gustav Brock) Date: Mon, 10 Mar 2014 13:19:31 +0000 Subject: [dba-SQLServer] PK/ANPK Debate Message-ID: Hi Arthur I always use an ID. Postal codes do change, US states may not but who knows? And ISO codes - like those for the countries - do change. It is just so much easier: A table, any table, has an Id. Period. /gustav -----Oprindelig meddelelse----- Fra: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Arthur Fuller Sendt: 10. marts 2014 13:43 Til: Discussion concerning MS SQL Server Emne: [dba-SQLServer] PK/ANPK Debate To start off the week, I thought that I would re-open the PK/ANPK debate, limiting the discussion to a specific group of tables: lookup tables. Consider this example: SCENARIO 1: Table: Volunteers PK: VolunteerID (autonumber) Columns: Name, Address, etc. Table: Languages PK: LanguageID (autonumber) Columns: Language(varchar(20) Associative Table: VolunteerLanguages PK: VolunteerID, LanguageID Columns: VolunteerID, LanguageID, and perhaps Profiency SCENARIO 2: Table: Volunteers PK: VolunteerID (autonumber) Columns: Name, Address, etc. Table: Languages PK: Language Columns: Language(varchar(20) Associative Table: VolunteerLanguages PK: VolunteerID, Language Columns: VolunteerID(int), Language(varchar(20), and perhaps Profiency Both scenarios exist to allow the recording of multi-lingual Volunteers. The knee-jerk choice is to go with the first scenario, but I am calling this into question, on the grounds that it complicates queries, comboBoxes etc. unnecessarily. The name of the language is sufficient as a PK in itself. No one wants duplicate occurrences of any language name in this table. In the associative table, the second Scenario takes up a little more space. But surely in this age when laptops have multi-TB hard disks, this is of no real concern. So why complicate queries, combos, listboxes etc. with a pointless lookup and additional Join? The same argument could be applied to many lookup tables, for example Countries? Why bother with an ANPK when the official ISO abbreviations exist, are easily obtained, and are universally recognized? Perhaps the argument is even stronger here, since the ISO codes are char(3)? In case it isn't clear, I am not arguing for this design in the common Customer+Orders+OrderItems situation, but only in the subset of tables where there are a small number of rows whose text values must be unique. In the past, I have designed this subset according to the first scenario, Scenario 1 demands either a unique index on the text column or logic in the front end to achieve the same thing. In short, I no longer see the point. -- Arthur From mcp2004 at mail.ru Mon Mar 10 13:05:53 2014 From: mcp2004 at mail.ru (=?UTF-8?B?U2FsYWtoZXRkaW5vdiBTaGFtaWw=?=) Date: Mon, 10 Mar 2014 22:05:53 +0400 Subject: [dba-SQLServer] =?utf-8?q?PK/ANPK_Debate?= In-Reply-To: References: Message-ID: <1394474753.912397930@f27.i.mail.ru> Hi Arthur -- >??I no longer see the point. You'd better keep "Pandora's box" closed. :) -- Shamil Monday, March 10, 2014 8:43 AM -04:00 from Arthur Fuller : >To start off the week, I thought that I would re-open the PK/ANPK debate, >limiting the discussion to a specific group of tables: lookup tables. >Consider this example: > >SCENARIO 1: >Table: Volunteers >PK: VolunteerID (autonumber) >Columns: Name, Address, etc. > >Table: Languages >PK: LanguageID (autonumber) >Columns: Language(varchar(20) > >Associative Table: VolunteerLanguages >PK: VolunteerID, LanguageID >Columns: VolunteerID, LanguageID, and perhaps Profiency > >SCENARIO 2: >Table: Volunteers >PK: VolunteerID (autonumber) >Columns: Name, Address, etc. > >Table: Languages >PK: Language >Columns: Language(varchar(20) > >Associative Table: VolunteerLanguages >PK: VolunteerID, Language >Columns: VolunteerID(int), Language(varchar(20), and perhaps Profiency > >Both scenarios exist to allow the recording of multi-lingual Volunteers. >The knee-jerk choice is to go with the first scenario, but I am calling >this into question, on the grounds that it complicates queries, comboBoxes >etc. unnecessarily. The name of the language is sufficient as a PK in >itself. No one wants duplicate occurrences of any language name in this >table. > >In the associative table, the second Scenario takes up a little more space. >But surely in this age when laptops have multi-TB hard disks, this is of no >real concern. So why complicate queries, combos, listboxes etc. with a >pointless lookup and additional Join? > >The same argument could be applied to many lookup tables, for example >Countries? Why bother with an ANPK when the official ISO abbreviations >exist, are easily obtained, and are universally recognized? Perhaps the >argument is even stronger here, since the ISO codes are char(3)? > >In case it isn't clear, I am not arguing for this design in the common >Customer+Orders+OrderItems situation, but only in the subset of tables >where there are a small number of rows whose text values must be unique. In >the past, I have designed this subset according to the first scenario, >Scenario 1 demands either a unique index on the text column or logic in the >front end to achieve the same thing. In short, I no longer see the point. > >-- >Arthur From stuart at lexacorp.com.pg Mon Mar 10 15:57:30 2014 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Tue, 11 Mar 2014 06:57:30 +1000 Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: References: Message-ID: <531E273A.469.313F208D@stuart.lexacorp.com.pg> I really shouldn't bite - but OK, here e go again. Seceral reasons 1. A 20 character string takes rakes up considerable more storage that a ANPK, in both the record and the index(es) 2. A 20 character string takes much longer to sort/filter than a number. and the biggie. What happens when you have a lot of records and someone decides that they want to change the name of a language ( Pidgin to Tok Pisin for example) I san again, natural keys which have meaning to the user are never appropriate as (part of) a PK. They will always be liable to change. I'd much rather go with the slight additional complexity of designing the user interface versus the above deificiencies. As for " either a unique index on the text". A text index on one occurrence of each item is a relatively short list has so little impact that it is not worth worrying about. -- Stuart On 10 Mar 2014 at 8:43, Arthur Fuller wrote: > To start off the week, I thought that I would re-open the PK/ANPK > debate, limiting the discussion to a specific group of tables: lookup > tables. Consider this example: > > SCENARIO 1: > Table: Volunteers > PK: VolunteerID (autonumber) > Columns: Name, Address, etc. > > Table: Languages > PK: LanguageID (autonumber) > Columns: Language(varchar(20) > > Associative Table: VolunteerLanguages > PK: VolunteerID, LanguageID > Columns: VolunteerID, LanguageID, and perhaps Profiency > > SCENARIO 2: > Table: Volunteers > PK: VolunteerID (autonumber) > Columns: Name, Address, etc. > > Table: Languages > PK: Language > Columns: Language(varchar(20) > > Associative Table: VolunteerLanguages > PK: VolunteerID, Language > Columns: VolunteerID(int), Language(varchar(20), and perhaps Profiency > > Both scenarios exist to allow the recording of multi-lingual > Volunteers. The knee-jerk choice is to go with the first scenario, but > I am calling this into question, on the grounds that it complicates > queries, comboBoxes etc. unnecessarily. The name of the language is > sufficient as a PK in itself. No one wants duplicate occurrences of > any language name in this table. > > In the associative table, the second Scenario takes up a little more > space. But surely in this age when laptops have multi-TB hard disks, > this is of no real concern. So why complicate queries, combos, > listboxes etc. with a pointless lookup and additional Join? > > The same argument could be applied to many lookup tables, for example > Countries? Why bother with an ANPK when the official ISO abbreviations > exist, are easily obtained, and are universally recognized? Perhaps > the argument is even stronger here, since the ISO codes are char(3)? > > In case it isn't clear, I am not arguing for this design in the common > Customer+Orders+OrderItems situation, but only in the subset of tables > where there are a small number of rows whose text values must be > unique. In the past, I have designed this subset according to the > first scenario, Scenario 1 demands either a unique index on the text > column or logic in the front end to achieve the same thing. In short, > I no longer see the point. > > -- > Arthur > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From stuart at lexacorp.com.pg Mon Mar 10 16:01:13 2014 From: stuart at lexacorp.com.pg (Stuart McLachlan) Date: Tue, 11 Mar 2014 07:01:13 +1000 Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: <1394474753.912397930@f27.i.mail.ru> References: , <1394474753.912397930@f27.i.mail.ru> Message-ID: <531E2819.22694.3142870C@stuart.lexacorp.com.pg> Too late :) On 10 Mar 2014 at 22:05, Salakhetdinov Shamil wrote: > Hi Arthur -- > > >??I no longer see the point. > You'd better keep "Pandora's box" closed. :) > > -- Shamil > > Monday, March 10, 2014 8:43 AM -04:00 from Arthur Fuller > : >To start off the week, I thought that I > would re-open the PK/ANPK debate, >limiting the discussion to a > specific group of tables: lookup tables. >Consider this example: > > >SCENARIO 1: >Table: Volunteers >PK: VolunteerID (autonumber) > >Columns: Name, Address, etc. > >Table: Languages >PK: LanguageID > (autonumber) >Columns: Language(varchar(20) > >Associative Table: > VolunteerLanguages >PK: VolunteerID, LanguageID >Columns: VolunteerID, > LanguageID, and perhaps Profiency > >SCENARIO 2: >Table: Volunteers > >PK: VolunteerID (autonumber) >Columns: Name, Address, etc. > >Table: > Languages >PK: Language >Columns: Language(varchar(20) > >Associative > Table: VolunteerLanguages >PK: VolunteerID, Language >Columns: > VolunteerID(int), Language(varchar(20), and perhaps Profiency > >Both > scenarios exist to allow the recording of multi-lingual Volunteers. > >The knee-jerk choice is to go with the first scenario, but I am > calling >this into question, on the grounds that it complicates > queries, comboBoxes >etc. unnecessarily. The name of the language is > sufficient as a PK in >itself. No one wants duplicate occurrences of > any language name in this >table. > >In the associative table, the > second Scenario takes up a little more space. >But surely in this age > when laptops have multi-TB hard disks, this is of no >real concern. So > why complicate queries, combos, listboxes etc. with a >pointless > lookup and additional Join? > >The same argument could be applied to > many lookup tables, for example >Countries? Why bother with an ANPK > when the official ISO abbreviations >exist, are easily obtained, and > are universally recognized? Perhaps the >argument is even stronger > here, since the ISO codes are char(3)? > >In case it isn't clear, I am > not arguing for this design in the common >Customer+Orders+OrderItems > situation, but only in the subset of tables >where there are a small > number of rows whose text values must be unique. In >the past, I have > designed this subset according to the first scenario, >Scenario 1 > demands either a unique index on the text column or logic in the > >front end to achieve the same thing. In short, I no longer see the > point. > >-- >Arthur _______________________________________________ > dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > From rockysmolin at bchacc.com Mon Mar 10 23:39:26 2014 From: rockysmolin at bchacc.com (Rocky Smolin) Date: Mon, 10 Mar 2014 21:39:26 -0700 Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: <531E273A.469.313F208D@stuart.lexacorp.com.pg> References: <531E273A.469.313F208D@stuart.lexacorp.com.pg> Message-ID: I ALWAYS start EVERY table design with an autonumber PK. Even when it makes no sense - like I'll never be doing a sort or find on this table. Still - just a habit - but I think it's a good one. I don't EVER have to think about the consequences of picking a non-autonumber primary key. As the philosopher says: "No brains, no headache." R -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan Sent: 10 March 2014 13:58 To: Discussion concerning MS SQL Server Subject: Re: [dba-SQLServer] PK/ANPK Debate I really shouldn't bite - but OK, here e go again. Seceral reasons 1. A 20 character string takes rakes up considerable more storage that a ANPK, in both the record and the index(es) 2. A 20 character string takes much longer to sort/filter than a number. and the biggie. What happens when you have a lot of records and someone decides that they want to change the name of a language ( Pidgin to Tok Pisin for example) I san again, natural keys which have meaning to the user are never appropriate as (part of) a PK. They will always be liable to change. I'd much rather go with the slight additional complexity of designing the user interface versus the above deificiencies. As for " either a unique index on the text". A text index on one occurrence of each item is a relatively short list has so little impact that it is not worth worrying about. -- Stuart On 10 Mar 2014 at 8:43, Arthur Fuller wrote: > To start off the week, I thought that I would re-open the PK/ANPK > debate, limiting the discussion to a specific group of tables: lookup > tables. Consider this example: > > SCENARIO 1: > Table: Volunteers > PK: VolunteerID (autonumber) > Columns: Name, Address, etc. > > Table: Languages > PK: LanguageID (autonumber) > Columns: Language(varchar(20) > > Associative Table: VolunteerLanguages > PK: VolunteerID, LanguageID > Columns: VolunteerID, LanguageID, and perhaps Profiency > > SCENARIO 2: > Table: Volunteers > PK: VolunteerID (autonumber) > Columns: Name, Address, etc. > > Table: Languages > PK: Language > Columns: Language(varchar(20) > > Associative Table: VolunteerLanguages > PK: VolunteerID, Language > Columns: VolunteerID(int), Language(varchar(20), and perhaps Profiency > > Both scenarios exist to allow the recording of multi-lingual > Volunteers. The knee-jerk choice is to go with the first scenario, but > I am calling this into question, on the grounds that it complicates > queries, comboBoxes etc. unnecessarily. The name of the language is > sufficient as a PK in itself. No one wants duplicate occurrences of > any language name in this table. > > In the associative table, the second Scenario takes up a little more > space. But surely in this age when laptops have multi-TB hard disks, > this is of no real concern. So why complicate queries, combos, > listboxes etc. with a pointless lookup and additional Join? > > The same argument could be applied to many lookup tables, for example > Countries? Why bother with an ANPK when the official ISO abbreviations > exist, are easily obtained, and are universally recognized? Perhaps > the argument is even stronger here, since the ISO codes are char(3)? > > In case it isn't clear, I am not arguing for this design in the common > Customer+Orders+OrderItems situation, but only in the subset of tables > where there are a small number of rows whose text values must be > unique. In the past, I have designed this subset according to the > first scenario, Scenario 1 demands either a unique index on the text > column or logic in the front end to achieve the same thing. In short, > I no longer see the point. > > -- > Arthur > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From marklbreen at gmail.com Tue Mar 11 04:49:02 2014 From: marklbreen at gmail.com (Mark Breen) Date: Tue, 11 Mar 2014 09:49:02 +0000 Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: References: Message-ID: Hello Arthur, About three years ago, I started to use a special table named Lookups. in that table I store all my system lookups in one table. I know it is not true referential integrity but it makes it extremely easy to add a new set of lookup values. My table structure is Id, ItemName (nvarchar(255), ItemValue Nvarchar(max) In there I might store a list of Colours, a list of status codes and a list of priorities, I may sometimes have ten or twenty different sets of lookup values. I name the foreign keys as follows Item name: Grades Foreign Key GradeLVId Item name: Colours Foreign ColourLVId When I app needs a new lookup table to store Shapes, I simply insert a few more records in the lookup table as follows Shapes, Square Shapes, Triangle, Shapes, heptakaidecagon I should add that I also have only have one screen to maintain all these different lookup items. *Summary* Since I switched to this structure for lookup values, I truly estimate that I have saved a lot of times and added flexibility to my applications. On 10 March 2014 12:43, Arthur Fuller wrote: > To start off the week, I thought that I would re-open the PK/ANPK debate, > limiting the discussion to a specific group of tables: lookup tables. > Consider this example: > > SCENARIO 1: > Table: Volunteers > PK: VolunteerID (autonumber) > Columns: Name, Address, etc. > > Table: Languages > PK: LanguageID (autonumber) > Columns: Language(varchar(20) > > Associative Table: VolunteerLanguages > PK: VolunteerID, LanguageID > Columns: VolunteerID, LanguageID, and perhaps Profiency > > SCENARIO 2: > Table: Volunteers > PK: VolunteerID (autonumber) > Columns: Name, Address, etc. > > Table: Languages > PK: Language > Columns: Language(varchar(20) > > Associative Table: VolunteerLanguages > PK: VolunteerID, Language > Columns: VolunteerID(int), Language(varchar(20), and perhaps Profiency > > Both scenarios exist to allow the recording of multi-lingual Volunteers. > The knee-jerk choice is to go with the first scenario, but I am calling > this into question, on the grounds that it complicates queries, comboBoxes > etc. unnecessarily. The name of the language is sufficient as a PK in > itself. No one wants duplicate occurrences of any language name in this > table. > > In the associative table, the second Scenario takes up a little more space. > But surely in this age when laptops have multi-TB hard disks, this is of no > real concern. So why complicate queries, combos, listboxes etc. with a > pointless lookup and additional Join? > > The same argument could be applied to many lookup tables, for example > Countries? Why bother with an ANPK when the official ISO abbreviations > exist, are easily obtained, and are universally recognized? Perhaps the > argument is even stronger here, since the ISO codes are char(3)? > > In case it isn't clear, I am not arguing for this design in the common > Customer+Orders+OrderItems situation, but only in the subset of tables > where there are a small number of rows whose text values must be unique. In > the past, I have designed this subset according to the first scenario, > Scenario 1 demands either a unique index on the text column or logic in the > front end to achieve the same thing. In short, I no longer see the point. > > -- > Arthur > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From ssharkins at gmail.com Tue Mar 11 05:52:20 2014 From: ssharkins at gmail.com (Susan Harkins) Date: Tue, 11 Mar 2014 06:52:20 -0400 Subject: [dba-SQLServer] PK/ANPK Debate Message-ID: Me too. :) On Tue, Mar 11, 2014 at 12:39 AM, Rocky Smolin wrote: > I ALWAYS start EVERY table design with an autonumber PK. Even when it makes > no sense - like I'll never be doing a sort or find on this table. Still - > just a habit - but I think it's a good one. I don't EVER have to think about > the consequences of picking a non-autonumber primary key. > > As the philosopher says: "No brains, no headache." > From fhtapia at gmail.com Tue Mar 11 07:15:25 2014 From: fhtapia at gmail.com (Francisco Tapia) Date: Tue, 11 Mar 2014 05:15:25 -0700 (PDT) Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: References: Message-ID: <1394540124491.179cd8fb@Nodemailer> Well since this has started off so well I'll throw my 2 cents.. I've seen this design within SAP. ?It makes for finding related lookups pretty easy but they do seperate their lookups so you don't have unrelated data together. ?Case in point they have a table simply for damage codes but the if maybe for damage codes in a service call or it might be from manufacturing, medical etc... As for anpk, why should coding up a lookup save me time as a programmer in my queries? My idea has always been optimize as much for data efficiency and speed! I know today's computers can run circles around yesterday's technology, but that's no reason for programmers to get sloppy with coding. ?If the argument really is, why complicate my query since machines today are so fast? Then why normalize at all? ?Just build it flat no joins no fuss problem solved no wierd ids in your table... It's hard to justify... ? Sent from Mailbox for iPhone On Tue, Mar 11, 2014 at 2:50 AM, Mark Breen wrote: > Hello Arthur, > About three years ago, I started to use a special table named Lookups. > in that table I store all my system lookups in one table. > I know it is not true referential integrity but it makes it extremely easy > to add a new set of lookup values. My table structure is > Id, ItemName (nvarchar(255), ItemValue Nvarchar(max) > In there I might store a list of Colours, a list of status codes and a list > of priorities, I may sometimes have ten or twenty different sets of lookup > values. > I name the foreign keys as follows > Item name: Grades > Foreign Key GradeLVId > Item name: Colours > Foreign ColourLVId > When I app needs a new lookup table to store Shapes, I simply insert a few > more records in the lookup table as follows > Shapes, Square > Shapes, Triangle, > Shapes, heptakaidecagon > I should add that I also have only have one screen to maintain all these > different lookup items. > *Summary* > Since I switched to this structure for lookup values, I truly estimate that > I have saved a lot of times and added flexibility to my applications. > On 10 March 2014 12:43, Arthur Fuller wrote: >> To start off the week, I thought that I would re-open the PK/ANPK debate, >> limiting the discussion to a specific group of tables: lookup tables. >> Consider this example: >> >> SCENARIO 1: >> Table: Volunteers >> PK: VolunteerID (autonumber) >> Columns: Name, Address, etc. >> >> Table: Languages >> PK: LanguageID (autonumber) >> Columns: Language(varchar(20) >> >> Associative Table: VolunteerLanguages >> PK: VolunteerID, LanguageID >> Columns: VolunteerID, LanguageID, and perhaps Profiency >> >> SCENARIO 2: >> Table: Volunteers >> PK: VolunteerID (autonumber) >> Columns: Name, Address, etc. >> >> Table: Languages >> PK: Language >> Columns: Language(varchar(20) >> >> Associative Table: VolunteerLanguages >> PK: VolunteerID, Language >> Columns: VolunteerID(int), Language(varchar(20), and perhaps Profiency >> >> Both scenarios exist to allow the recording of multi-lingual Volunteers. >> The knee-jerk choice is to go with the first scenario, but I am calling >> this into question, on the grounds that it complicates queries, comboBoxes >> etc. unnecessarily. The name of the language is sufficient as a PK in >> itself. No one wants duplicate occurrences of any language name in this >> table. >> >> In the associative table, the second Scenario takes up a little more space. >> But surely in this age when laptops have multi-TB hard disks, this is of no >> real concern. So why complicate queries, combos, listboxes etc. with a >> pointless lookup and additional Join? >> >> The same argument could be applied to many lookup tables, for example >> Countries? Why bother with an ANPK when the official ISO abbreviations >> exist, are easily obtained, and are universally recognized? Perhaps the >> argument is even stronger here, since the ISO codes are char(3)? >> >> In case it isn't clear, I am not arguing for this design in the common >> Customer+Orders+OrderItems situation, but only in the subset of tables >> where there are a small number of rows whose text values must be unique. In >> the past, I have designed this subset according to the first scenario, >> Scenario 1 demands either a unique index on the text column or logic in the >> front end to achieve the same thing. In short, I no longer see the point. >> >> -- >> Arthur >> _______________________________________________ >> dba-SQLServer mailing list >> dba-SQLServer at databaseadvisors.com >> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >> http://www.databaseadvisors.com >> >> > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com From rls at WeBeDb.com Tue Mar 11 09:01:11 2014 From: rls at WeBeDb.com (Robert Stewart) Date: Tue, 11 Mar 2014 09:01:11 -0500 Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: References: Message-ID: <87FD5CF9-7238-469C-816D-012085C98897@holly.arvixe.com> Arthur, Languages, like Countries, have standard ISO codes, but there are also changes being made to them, like countries. Because of that, an autonumber primary key is pretty much required so changes are not cascaded. I always do a surrogate PK in every table. It is just good design. If you start with a method, you stay with a method. Consistent design... Robert At 11:39 PM 3/10/2014, you wrote: >Date: Mon, 10 Mar 2014 08:43:16 -0400 >From: Arthur Fuller >To: Discussion concerning MS SQL Server > >Subject: [dba-SQLServer] PK/ANPK Debate > >To start off the week, I thought that I would re-open the PK/ANPK debate, >limiting the discussion to a specific group of tables: lookup tables. >Consider this example: > >SCENARIO 1: >Table: Volunteers >PK: VolunteerID (autonumber) >Columns: Name, Address, etc. > >Table: Languages >PK: LanguageID (autonumber) >Columns: Language(varchar(20) > >Associative Table: VolunteerLanguages >PK: VolunteerID, LanguageID >Columns: VolunteerID, LanguageID, and perhaps Profiency > >SCENARIO 2: >Table: Volunteers >PK: VolunteerID (autonumber) >Columns: Name, Address, etc. > >Table: Languages >PK: Language >Columns: Language(varchar(20) > >Associative Table: VolunteerLanguages >PK: VolunteerID, Language >Columns: VolunteerID(int), Language(varchar(20), and perhaps Profiency > >Both scenarios exist to allow the recording of multi-lingual Volunteers. >The knee-jerk choice is to go with the first scenario, but I am calling >this into question, on the grounds that it complicates queries, comboBoxes >etc. unnecessarily. The name of the language is sufficient as a PK in >itself. No one wants duplicate occurrences of any language name in this >table. > >In the associative table, the second Scenario takes up a little more space. >But surely in this age when laptops have multi-TB hard disks, this is of no >real concern. So why complicate queries, combos, listboxes etc. with a >pointless lookup and additional Join? > >The same argument could be applied to many lookup tables, for example >Countries? Why bother with an ANPK when the official ISO abbreviations >exist, are easily obtained, and are universally recognized? Perhaps the >argument is even stronger here, since the ISO codes are char(3)? > >In case it isn't clear, I am not arguing for this design in the common >Customer+Orders+OrderItems situation, but only in the subset of tables >where there are a small number of rows whose text values must be unique. In >the past, I have designed this subset according to the first scenario, >Scenario 1 demands either a unique index on the text column or logic in the >front end to achieve the same thing. In short, I no longer see the point. > >-- >Arthur Robert L. Stewart Any fool can write code that a computer can understand. Good programmers write code that humans can understand. --Martin Fowler www.WeBeDb.com www.DBGUIDesign.com www.RLStewartPhotography.com From marklbreen at gmail.com Tue Mar 11 11:17:27 2014 From: marklbreen at gmail.com (Mark Breen) Date: Tue, 11 Mar 2014 16:17:27 +0000 Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: <1394540124491.179cd8fb@Nodemailer> References: <1394540124491.179cd8fb@Nodemailer> Message-ID: Hi Francisco thanks for the reply. Just on question, not sure what you mean when you said >As for anpk, why should coding up a lookup save me time as a programmer in my queries? Hope you are well Mark On 11 March 2014 12:15, Francisco Tapia wrote: > Well since this has started off so well I'll throw my 2 cents.. > > > > I've seen this design within SAP. It makes for finding related lookups > pretty easy but they do seperate their lookups so you don't have unrelated > data together. Case in point they have a table simply for damage codes but > the if maybe for damage codes in a service call or it might be from > manufacturing, medical etc... > > > As for anpk, why should coding up a lookup save me time as a programmer in > my queries? > > > > > My idea has always been optimize as much for data efficiency and speed! I > know today's computers can run circles around yesterday's technology, but > that's no reason for programmers to get sloppy with coding. If the > argument really is, why complicate my query since machines today are so > fast? Then why normalize at all? Just build it flat no joins no fuss > problem solved no wierd ids in your table... > > > > > It's hard to justify... > -- > Sent from Mailbox for iPhone > > On Tue, Mar 11, 2014 at 2:50 AM, Mark Breen wrote: > > > Hello Arthur, > > About three years ago, I started to use a special table named Lookups. > > in that table I store all my system lookups in one table. > > I know it is not true referential integrity but it makes it extremely > easy > > to add a new set of lookup values. My table structure is > > Id, ItemName (nvarchar(255), ItemValue Nvarchar(max) > > In there I might store a list of Colours, a list of status codes and a > list > > of priorities, I may sometimes have ten or twenty different sets of > lookup > > values. > > I name the foreign keys as follows > > Item name: Grades > > Foreign Key GradeLVId > > Item name: Colours > > Foreign ColourLVId > > When I app needs a new lookup table to store Shapes, I simply insert a > few > > more records in the lookup table as follows > > Shapes, Square > > Shapes, Triangle, > > Shapes, heptakaidecagon > > I should add that I also have only have one screen to maintain all these > > different lookup items. > > *Summary* > > Since I switched to this structure for lookup values, I truly estimate > that > > I have saved a lot of times and added flexibility to my applications. > > On 10 March 2014 12:43, Arthur Fuller wrote: > >> To start off the week, I thought that I would re-open the PK/ANPK > debate, > >> limiting the discussion to a specific group of tables: lookup tables. > >> Consider this example: > >> > >> SCENARIO 1: > >> Table: Volunteers > >> PK: VolunteerID (autonumber) > >> Columns: Name, Address, etc. > >> > >> Table: Languages > >> PK: LanguageID (autonumber) > >> Columns: Language(varchar(20) > >> > >> Associative Table: VolunteerLanguages > >> PK: VolunteerID, LanguageID > >> Columns: VolunteerID, LanguageID, and perhaps Profiency > >> > >> SCENARIO 2: > >> Table: Volunteers > >> PK: VolunteerID (autonumber) > >> Columns: Name, Address, etc. > >> > >> Table: Languages > >> PK: Language > >> Columns: Language(varchar(20) > >> > >> Associative Table: VolunteerLanguages > >> PK: VolunteerID, Language > >> Columns: VolunteerID(int), Language(varchar(20), and perhaps Profiency > >> > >> Both scenarios exist to allow the recording of multi-lingual Volunteers. > >> The knee-jerk choice is to go with the first scenario, but I am calling > >> this into question, on the grounds that it complicates queries, > comboBoxes > >> etc. unnecessarily. The name of the language is sufficient as a PK in > >> itself. No one wants duplicate occurrences of any language name in this > >> table. > >> > >> In the associative table, the second Scenario takes up a little more > space. > >> But surely in this age when laptops have multi-TB hard disks, this is > of no > >> real concern. So why complicate queries, combos, listboxes etc. with a > >> pointless lookup and additional Join? > >> > >> The same argument could be applied to many lookup tables, for example > >> Countries? Why bother with an ANPK when the official ISO abbreviations > >> exist, are easily obtained, and are universally recognized? Perhaps the > >> argument is even stronger here, since the ISO codes are char(3)? > >> > >> In case it isn't clear, I am not arguing for this design in the common > >> Customer+Orders+OrderItems situation, but only in the subset of tables > >> where there are a small number of rows whose text values must be > unique. In > >> the past, I have designed this subset according to the first scenario, > >> Scenario 1 demands either a unique index on the text column or logic in > the > >> front end to achieve the same thing. In short, I no longer see the > point. > >> > >> -- > >> Arthur > >> _______________________________________________ > >> dba-SQLServer mailing list > >> dba-SQLServer at databaseadvisors.com > >> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > >> http://www.databaseadvisors.com > >> > >> > > _______________________________________________ > > dba-SQLServer mailing list > > dba-SQLServer at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > http://www.databaseadvisors.com > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From fhtapia at gmail.com Tue Mar 11 14:23:48 2014 From: fhtapia at gmail.com (Francisco Tapia) Date: Tue, 11 Mar 2014 12:23:48 -0700 Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: References: <1394540124491.179cd8fb@Nodemailer> Message-ID: On Tue, Mar 11, 2014 at 9:17 AM, Mark Breen wrote: > Just on question, not sure what you mean when you said > > >As for anpk, why should coding up a lookup save me time as a programmer in > my queries? > Hey Mark, sorry, I was not very clear there, I combined my response which is what Arthur was initially stating, was, why not save the developer some query brain power. I stand by my response, I can re-architect a solution so I code it as fast as possible taking every conceivable shortcut especially when you consider how fast computers are today, most of my bad coding practices perhaps would not surface initially, though it wouldn't scale once you began to roll it out. the ANPK solution as you setup is one way to create a simple shortcut that does not impact the system negatively. The important thing is to stay consistent. in the manner that SAP builds their lookup tables they like to group things up, so all damage code related lookups are grouped together. But which ever way you do it your actual FKID is an autonumber and that makes it nice and easy to update if you should have to for some reason down the line. -Francisco From fuller.artful at gmail.com Tue Mar 11 14:32:11 2014 From: fuller.artful at gmail.com (Arthur Fuller) Date: Tue, 11 Mar 2014 15:32:11 -0400 Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: References: <1394540124491.179cd8fb@Nodemailer> Message-ID: Well, my principal mission has been achieved! Said mission was not to prove or even posit my point, but to kick the ashes and see whether the embers are still burning. And they are! Nothing like a hot topic to awake the sleeping dragons. Happy to see that you're all alive and well. A. From fhtapia at gmail.com Tue Mar 11 14:40:38 2014 From: fhtapia at gmail.com (Francisco Tapia) Date: Tue, 11 Mar 2014 12:40:38 -0700 Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: References: <1394540124491.179cd8fb@Nodemailer> Message-ID: On Tue, Mar 11, 2014 at 12:32 PM, Arthur Fuller wrote: > Said mission was not to prove > or even posit my point, but to kick the ashes and see whether the embers > are still burning. And they are! Nothing like a hot topic to awake the > sleeping dragons. > hahaha, you know this topic sparks an un-holy war! XD It's even more religious than the thou shall not use cursors in your SQL!!! lol -Francisco From fuller.artful at gmail.com Tue Mar 11 14:49:03 2014 From: fuller.artful at gmail.com (Arthur Fuller) Date: Tue, 11 Mar 2014 15:49:03 -0400 Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: References: <1394540124491.179cd8fb@Nodemailer> Message-ID: Right on, Francisco! From darryl at whittleconsulting.com.au Tue Mar 11 19:00:25 2014 From: darryl at whittleconsulting.com.au (Darryl Collins) Date: Wed, 12 Mar 2014 00:00:25 +0000 Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: References: <1394540124491.179cd8fb@Nodemailer> Message-ID: Bound vs Unbound controls also seems to be a topic that gets folks, ummm, passionate, about their position I have noted... -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francisco Tapia Sent: Wednesday, 12 March 2014 6:41 AM To: Discussion concerning MS SQL Server Subject: Re: [dba-SQLServer] PK/ANPK Debate On Tue, Mar 11, 2014 at 12:32 PM, Arthur Fuller wrote: > Said mission was not to prove > or even posit my point, but to kick the ashes and see whether the > embers are still burning. And they are! Nothing like a hot topic to > awake the sleeping dragons. > hahaha, you know this topic sparks an un-holy war! XD It's even more religious than the thou shall not use cursors in your SQL!!! lol -Francisco _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From marklbreen at gmail.com Tue Mar 11 19:06:26 2014 From: marklbreen at gmail.com (Mark Breen) Date: Wed, 12 Mar 2014 00:06:26 +0000 Subject: [dba-SQLServer] Design first without Id column - was Arthurs thread Message-ID: Hi Arthur and everyone else, Changing the subject slightly here May I draw everyones attention to a fascinating concept I saw in a presentation I had two years ago at an SQLSaturday event. A brilliant database lady, whose name escapes me tortured the room by challenging our existing methods of doing things. I will not list all the 'rules' that she demonstrated could and should be broken but eventually she got onto the natural / artificial pk design. She eventually admitted that she always uses an artificial key for implementation but she completes all her db designs initially without and artificial keys. By building a preliminary db without any Id cols, she instructed that it forces us to really identify what data is being stored and related in in each table. By doing a design without the Id columns, you need to get your data correct. Once you are done, then she adds in the Ids and git's to coding. I am not suggesting stop using Ids, but it is a neat idea in the design to attempt it without those columns. Theory is that when you cannot, you possible do not fully have the db design correct yet. Of any interest? Mark On 11 March 2014 19:32, Arthur Fuller wrote: > Well, my principal mission has been achieved! Said mission was not to prove > or even posit my point, but to kick the ashes and see whether the embers > are still burning. And they are! Nothing like a hot topic to awake the > sleeping dragons. > > Happy to see that you're all alive and well. > > A. > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From ssharkins at gmail.com Tue Mar 11 19:13:17 2014 From: ssharkins at gmail.com (Susan Harkins) Date: Tue, 11 Mar 2014 20:13:17 -0400 Subject: [dba-SQLServer] Design first without Id column - was Arthurs thread In-Reply-To: References: Message-ID: Mark, that route would probably force better/truer normalization as well. Susan H. On Tue, Mar 11, 2014 at 8:06 PM, Mark Breen wrote: > Hi Arthur and everyone else, > > Changing the subject slightly here > > May I draw everyones attention to a fascinating concept I saw in a > presentation I had two years ago at an SQLSaturday event. > > A brilliant database lady, whose name escapes me tortured the room by > challenging our existing methods of doing things. I will not list all the > 'rules' that she demonstrated could and should be broken but eventually she > got onto the natural / artificial pk design. > > She eventually admitted that she always uses an artificial key for > implementation but she completes all her db designs initially without and > artificial keys. > > By building a preliminary db without any Id cols, she instructed that it > forces us to really identify what data is being stored and related in in > each table. By doing a design without the Id columns, you need to get > your data correct. Once you are done, then she adds in the Ids and git's > to coding. > > I am not suggesting stop using Ids, but it is a neat idea in the design to > attempt it without those columns. Theory is that when you cannot, you > possible do not fully have the db design correct yet. > > Of any interest? > > Mark > > > > > > > > > On 11 March 2014 19:32, Arthur Fuller wrote: > >> Well, my principal mission has been achieved! Said mission was not to prove >> or even posit my point, but to kick the ashes and see whether the embers >> are still burning. And they are! Nothing like a hot topic to awake the >> sleeping dragons. >> >> Happy to see that you're all alive and well. >> >> A. >> >> _______________________________________________ >> dba-SQLServer mailing list >> dba-SQLServer at databaseadvisors.com >> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver >> http://www.databaseadvisors.com >> >> > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > From darryl at whittleconsulting.com.au Tue Mar 11 19:14:01 2014 From: darryl at whittleconsulting.com.au (Darryl Collins) Date: Wed, 12 Mar 2014 00:14:01 +0000 Subject: [dba-SQLServer] Design first without Id column - was Arthurs thread In-Reply-To: References: Message-ID: Sure, I can see value in that. Indeed I have even done exactly that before. The latest DB solution I have built does this on the fly. The imported data only has natural keys. After it is imported I build the unique tables with numerical PK's and then reproduce all the text only tables with the keys. Fun stuff, and it does force you to understand exactly what the source data is and how it is related to all the other data tables. That's my experience anyway. Cheers Darryl -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Mark Breen Sent: Wednesday, 12 March 2014 11:06 AM To: Discussion concerning MS SQL Server Subject: [dba-SQLServer] Design first without Id column - was Arthurs thread Hi Arthur and everyone else, Changing the subject slightly here May I draw everyones attention to a fascinating concept I saw in a presentation I had two years ago at an SQLSaturday event. A brilliant database lady, whose name escapes me tortured the room by challenging our existing methods of doing things. I will not list all the 'rules' that she demonstrated could and should be broken but eventually she got onto the natural / artificial pk design. She eventually admitted that she always uses an artificial key for implementation but she completes all her db designs initially without and artificial keys. By building a preliminary db without any Id cols, she instructed that it forces us to really identify what data is being stored and related in in each table. By doing a design without the Id columns, you need to get your data correct. Once you are done, then she adds in the Ids and git's to coding. I am not suggesting stop using Ids, but it is a neat idea in the design to attempt it without those columns. Theory is that when you cannot, you possible do not fully have the db design correct yet. Of any interest? Mark On 11 March 2014 19:32, Arthur Fuller wrote: > Well, my principal mission has been achieved! Said mission was not to > prove or even posit my point, but to kick the ashes and see whether > the embers are still burning. And they are! Nothing like a hot topic > to awake the sleeping dragons. > > Happy to see that you're all alive and well. > > A. > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From mcp2004 at mail.ru Wed Mar 12 00:25:55 2014 From: mcp2004 at mail.ru (=?UTF-8?B?U2FsYWtoZXRkaW5vdiBTaGFtaWw=?=) Date: Wed, 12 Mar 2014 09:25:55 +0400 Subject: [dba-SQLServer] =?utf-8?q?PK/ANPK_Debate?= In-Reply-To: References: Message-ID: <1394601955.985755465@f372.i.mail.ru> Yes, but here in dba-SQL-Server "SQL Server vs. NoSQL" "holy war" thread would be more suitable than "Bound vs Unbound controls", should we ask Arthur to initiate it? ;) Wednesday, March 12, 2014 12:00 AM UTC from Darryl Collins : >Bound vs Unbound controls also seems to be a topic that gets folks, ummm, passionate, about their position I have noted... > > > >-----Original Message----- >From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francisco Tapia >Sent: Wednesday, 12 March 2014 6:41 AM >To: Discussion concerning MS SQL Server >Subject: Re: [dba-SQLServer] PK/ANPK Debate > >On Tue, Mar 11, 2014 at 12:32 PM, Arthur Fuller < fuller.artful at gmail.com >wrote: > >> Said mission was not to prove >> or even posit my point, but to kick the ashes and see whether the >> embers are still burning. And they are! Nothing like a hot topic to >> awake the sleeping dragons. >> > >hahaha, you know this topic sparks an un-holy war! XD > >It's even more religious than the thou shall not use cursors in your SQL!!! >lol > > From darryl at whittleconsulting.com.au Wed Mar 12 00:37:26 2014 From: darryl at whittleconsulting.com.au (Darryl Collins) Date: Wed, 12 Mar 2014 05:37:26 +0000 Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: <1394601955.985755465@f372.i.mail.ru> References: <1394601955.985755465@f372.i.mail.ru> Message-ID: <8c2cf658a3f748a9b16abfdbf1cc226b@HKXPR04MB184.apcprd04.prod.outlook.com> Hehehehe.. Indeed indeed. Who needs SQL anyway ;) -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Salakhetdinov Shamil Sent: Wednesday, 12 March 2014 4:26 PM To: Discussion concerning MS SQL Server Subject: Re: [dba-SQLServer] PK/ANPK Debate Yes, but here in dba-SQL-Server "SQL Server vs. NoSQL" "holy war" thread would be more suitable than "Bound vs Unbound controls", should we ask Arthur to initiate it? ;) Wednesday, March 12, 2014 12:00 AM UTC from Darryl Collins : >Bound vs Unbound controls also seems to be a topic that gets folks, ummm, passionate, about their position I have noted... > > > >-----Original Message----- >From: dba-sqlserver-bounces at databaseadvisors.com >[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of >Francisco Tapia >Sent: Wednesday, 12 March 2014 6:41 AM >To: Discussion concerning MS SQL Server >Subject: Re: [dba-SQLServer] PK/ANPK Debate > >On Tue, Mar 11, 2014 at 12:32 PM, Arthur Fuller < fuller.artful at gmail.com >wrote: > >> Said mission was not to prove >> or even posit my point, but to kick the ashes and see whether the >> embers are still burning. And they are! Nothing like a hot topic to >> awake the sleeping dragons. >> > >hahaha, you know this topic sparks an un-holy war! XD > >It's even more religious than the thou shall not use cursors in your SQL!!! >lol > > _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From marklbreen at gmail.com Wed Mar 12 03:57:25 2014 From: marklbreen at gmail.com (Mark Breen) Date: Wed, 12 Mar 2014 08:57:25 +0000 Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: <1394601955.985755465@f372.i.mail.ru> References: <1394601955.985755465@f372.i.mail.ru> Message-ID: Hello Shamil, yes, I agree completely, this is a much more up to date thread to discuss. I worked on a project last year that had to store thousands or tens of thousands of records. However, they wanted 100% failsafe fail over. They used two mongo dbs and they told me the db's just take care of they syncing. That is interesting to me. Nowadays with hardware so cheap, it is interesting to think that we can have two or three servers running our BE. But as you are hinting at, it is a new mindshift, one that we have to open up to sooner or later, not necessarily to store billions or records, but as a new way to store data. Mark On 12 March 2014 05:25, Salakhetdinov Shamil wrote: > Yes, but here in dba-SQL-Server "SQL Server vs. NoSQL" "holy war" thread > would be more suitable than "Bound vs Unbound controls", should we ask > Arthur to initiate it? ;) > > > Wednesday, March 12, 2014 12:00 AM UTC from Darryl Collins < > darryl at whittleconsulting.com.au>: > >Bound vs Unbound controls also seems to be a topic that gets folks, > ummm, passionate, about their position I have noted... > > > > > > > >-----Original Message----- > >From: dba-sqlserver-bounces at databaseadvisors.com [mailto: > dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francisco Tapia > >Sent: Wednesday, 12 March 2014 6:41 AM > >To: Discussion concerning MS SQL Server > >Subject: Re: [dba-SQLServer] PK/ANPK Debate > > > >On Tue, Mar 11, 2014 at 12:32 PM, Arthur Fuller < fuller.artful at gmail.com>wrote: > > > >> Said mission was not to prove > >> or even posit my point, but to kick the ashes and see whether the > >> embers are still burning. And they are! Nothing like a hot topic to > >> awake the sleeping dragons. > >> > > > >hahaha, you know this topic sparks an un-holy war! XD > > > >It's even more religious than the thou shall not use cursors in your > SQL!!! > >lol > > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From gustav at cactus.dk Wed Mar 12 04:31:01 2014 From: gustav at cactus.dk (Gustav Brock) Date: Wed, 12 Mar 2014 09:31:01 +0000 Subject: [dba-SQLServer] PK/ANPK Debate Message-ID: Hi Mark But were the data structure so that you just as well could have used relational SQL storage? /gustav -----Oprindelig meddelelse----- Fra: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Mark Breen Sendt: 12. marts 2014 09:57 Til: Discussion concerning MS SQL Server Emne: Re: [dba-SQLServer] PK/ANPK Debate Hello Shamil, yes, I agree completely, this is a much more up to date thread to discuss. I worked on a project last year that had to store thousands or tens of thousands of records. However, they wanted 100% failsafe fail over. They used two mongo dbs and they told me the db's just take care of they syncing. That is interesting to me. Nowadays with hardware so cheap, it is interesting to think that we can have two or three servers running our BE. But as you are hinting at, it is a new mindshift, one that we have to open up to sooner or later, not necessarily to store billions or records, but as a new way to store data. Mark On 12 March 2014 05:25, Salakhetdinov Shamil wrote: > Yes, but here in dba-SQL-Server "SQL Server vs. NoSQL" "holy war" > thread would be more suitable than "Bound vs Unbound controls", should > we ask Arthur to initiate it? ;) From fhtapia at gmail.com Wed Mar 12 09:19:04 2014 From: fhtapia at gmail.com (Francisco Tapia) Date: Wed, 12 Mar 2014 07:19:04 -0700 Subject: [dba-SQLServer] SQL Server vs. NoSQL Message-ID: On Tue, Mar 11, 2014 at 10:25 PM, Salakhetdinov Shamil wrote: > Yes, but here in dba-SQL-Server "SQL Server vs. NoSQL" "holy war" thread > would be more suitable than "Bound vs Unbound controls", should we ask > Arthur to initiate it? ;) > I'll kick in with a devil's advocate argument :) The argument for NoSQL are very attractive, speed, and scalability seems to be about the strongest argument. This of course hand in hand with volume of data, but even if you do not have terabytes of data, you can still get solid performance improvements over standard MS SQL Server solutions... I believe that is why the 2014 SQL Server solution will feature in memory tables, it's not noSql, it's more of a "Fusion Drive" for Sql Server, i remember reading in the past as I have not worked with the 2014 CTP version, that stored procedures that reference in memory tables exclusively can be natively compiled which I think makes them faster, but I guess we will see. I like the arguments for NoSQL for speed, and I think this is great as it pushes MS to come up with a new optimized solution. -Francisco From fhtapia at gmail.com Wed Mar 12 09:27:30 2014 From: fhtapia at gmail.com (Francisco Tapia) Date: Wed, 12 Mar 2014 07:27:30 -0700 Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: References: <1394540124491.179cd8fb@Nodemailer> Message-ID: On Tue, Mar 11, 2014 at 5:00 PM, Darryl Collins < darryl at whittleconsulting.com.au> wrote: > Bound vs Unbound controls also seems to be a topic that gets folks, ummm, > passionate, about their position I have noted... > only because the bound folks can't disassociate with the the critical requirement in today's world of being disconnected from the datasource for local caching and synching ;-) [granade thrown...] -Francisco From fuller.artful at gmail.com Wed Mar 12 10:06:14 2014 From: fuller.artful at gmail.com (Arthur Fuller) Date: Wed, 12 Mar 2014 11:06:14 -0400 Subject: [dba-SQLServer] Design first without Id column - was Arthurs thread In-Reply-To: References: Message-ID: Mark et. al. In terms of data-modeling, this describes the difference between Logical and Physical data models. Logical describes a database in terms closer to human than to machine. Physical describes the actual implementation, taking into account such features as Sequences (Oracle for example). Logical describes the domain without regard for which RDMS one ultimately chooses. Tools such as ERWin, PowerDesigner, etc. exist because of this division. At the Logical level, the focus is on the problem or challenge or domain, and good tools free you from commitment to any particular RDMS. We do our design at the LDM level, and only when that level is satisfied (i.e. fully descriptive) do we move to the PDM level, whose choice of RDMS may have absolutely nothing to do with the particular problem (i.e. "We're an Oracle shop and that's that."). I've been in the db game for 3+ decades, and I deem data-modeling tools absolutely vital, even for relatively small apps consisting of say 20 tables or fewer. I've also, in fact more frequently, been on the farther end of the spectrum, designing systems involving 500+ tables; in those situations, you'd have to be either insane or masochistic or some combination of both to try it by hand. A. From accessd at shaw.ca Wed Mar 12 19:53:15 2014 From: accessd at shaw.ca (Jim Lawrence) Date: Wed, 12 Mar 2014 18:53:15 -0600 (MDT) Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: Message-ID: <2096328835.1497568.1394671995083.JavaMail.root@cds018> Hi Francisco: I think that whole discussion has moved on. I seriously doubt whether suggesting a "bound" database is even an issue now, is a stretch and those still supporting it, IMHO, are on pare with members of "The Fall-Earth Society". The "bound" argument was flimsy even back in the late nineties or as soon a real ACID databases became the industry standard...and the realization that there was just not enough band-width, nodes or servers to support object binding. Jim ----- Original Message ----- From: "Francisco Tapia" To: "Discussion concerning MS SQL Server" Sent: Wednesday, March 12, 2014 7:27:30 AM Subject: Re: [dba-SQLServer] PK/ANPK Debate On Tue, Mar 11, 2014 at 5:00 PM, Darryl Collins < darryl at whittleconsulting.com.au> wrote: > Bound vs Unbound controls also seems to be a topic that gets folks, ummm, > passionate, about their position I have noted... > only because the bound folks can't disassociate with the the critical requirement in today's world of being disconnected from the datasource for local caching and synching ;-) [granade thrown...] -Francisco _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From darryl at whittleconsulting.com.au Wed Mar 12 22:17:49 2014 From: darryl at whittleconsulting.com.au (Darryl Collins) Date: Thu, 13 Mar 2014 03:17:49 +0000 Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: <2096328835.1497568.1394671995083.JavaMail.root@cds018> References: <2096328835.1497568.1394671995083.JavaMail.root@cds018> Message-ID: <6615857a2936463f8d72819952718935@HKXPR04MB184.apcprd04.prod.outlook.com> Yeah, I would have hoped we have moved on by now. For what it is worth, I have been firmly in the unbound camp for many years. Regards Darryl. -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, 13 March 2014 11:53 AM To: Discussion concerning MS SQL Server Subject: Re: [dba-SQLServer] PK/ANPK Debate Hi Francisco: I think that whole discussion has moved on. I seriously doubt whether suggesting a "bound" database is even an issue now, is a stretch and those still supporting it, IMHO, are on pare with members of "The Fall-Earth Society". The "bound" argument was flimsy even back in the late nineties or as soon a real ACID databases became the industry standard...and the realization that there was just not enough band-width, nodes or servers to support object binding. Jim ----- Original Message ----- From: "Francisco Tapia" To: "Discussion concerning MS SQL Server" Sent: Wednesday, March 12, 2014 7:27:30 AM Subject: Re: [dba-SQLServer] PK/ANPK Debate On Tue, Mar 11, 2014 at 5:00 PM, Darryl Collins < darryl at whittleconsulting.com.au> wrote: > Bound vs Unbound controls also seems to be a topic that gets folks, > ummm, passionate, about their position I have noted... > only because the bound folks can't disassociate with the the critical requirement in today's world of being disconnected from the datasource for local caching and synching ;-) [granade thrown...] -Francisco _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From stuart.mclachlan at gmail.com Thu Mar 13 03:28:03 2014 From: stuart.mclachlan at gmail.com (Stuart McLachlan) Date: Thu, 13 Mar 2014 18:28:03 +1000 Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: <6615857a2936463f8d72819952718935@HKXPR04MB184.apcprd04.prod.outlook.com> References: , <2096328835.1497568.1394671995083.JavaMail.root@cds018>, <6615857a2936463f8d72819952718935@HKXPR04MB184.apcprd04.prod.outlook.com> Message-ID: <53216C13.12437.1A80249@stuart.lexacorp.com.pg> Access FE to Access BE - almost total bound. Access FE to SQL Server/MySQL BE - sometimes bound/ sometines unbound depending on the circumstances and the datasets involved. Any other FE to any BE - total unbound. -- Stuart On 13 Mar 2014 at 3:17, Darryl Collins wrote: > Yeah, I would have hoped we have moved on by now. For what it is > worth, I have been firmly in the unbound camp for many years. > > Regards > Darryl. > > > -----Original Message----- > From: dba-sqlserver-bounces at databaseadvisors.com > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim > Lawrence Sent: Thursday, 13 March 2014 11:53 AM To: Discussion > concerning MS SQL Server Subject: Re: [dba-SQLServer] PK/ANPK Debate > > Hi Francisco: > > I think that whole discussion has moved on. I seriously doubt whether > suggesting a "bound" database is even an issue now, is a stretch and > those still supporting it, IMHO, are on pare with members of "The > Fall-Earth Society". The "bound" argument was flimsy even back in the > late nineties or as soon a real ACID databases became the industry > standard...and the realization that there was just not enough > band-width, nodes or servers to support object binding. > > Jim > > ----- Original Message ----- > From: "Francisco Tapia" > To: "Discussion concerning MS SQL Server" > Sent: Wednesday, March 12, 2014 > 7:27:30 AM Subject: Re: [dba-SQLServer] PK/ANPK Debate > > On Tue, Mar 11, 2014 at 5:00 PM, Darryl Collins < > darryl at whittleconsulting.com.au> wrote: > > > Bound vs Unbound controls also seems to be a topic that gets folks, > > ummm, passionate, about their position I have noted... > > > > only because the bound folks can't disassociate with the the critical > requirement in today's world of being disconnected from the datasource > for local caching and synching ;-) > > [granade thrown...] > > > -Francisco > _______________________________________________ dba-SQLServer mailing > list dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From accessd at shaw.ca Thu Mar 13 11:12:57 2014 From: accessd at shaw.ca (Jim Lawrence) Date: Thu, 13 Mar 2014 10:12:57 -0600 (MDT) Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: <6615857a2936463f8d72819952718935@HKXPR04MB184.apcprd04.prod.outlook.com> Message-ID: <1597398033.1899147.1394727177831.JavaMail.root@cds018> :-) Jim ----- Original Message ----- From: "Darryl Collins" To: "Discussion concerning MS SQL Server" Sent: Wednesday, March 12, 2014 8:17:49 PM Subject: Re: [dba-SQLServer] PK/ANPK Debate Yeah, I would have hoped we have moved on by now. For what it is worth, I have been firmly in the unbound camp for many years. Regards Darryl. -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence Sent: Thursday, 13 March 2014 11:53 AM To: Discussion concerning MS SQL Server Subject: Re: [dba-SQLServer] PK/ANPK Debate Hi Francisco: I think that whole discussion has moved on. I seriously doubt whether suggesting a "bound" database is even an issue now, is a stretch and those still supporting it, IMHO, are on pare with members of "The Fall-Earth Society". The "bound" argument was flimsy even back in the late nineties or as soon a real ACID databases became the industry standard...and the realization that there was just not enough band-width, nodes or servers to support object binding. Jim ----- Original Message ----- From: "Francisco Tapia" To: "Discussion concerning MS SQL Server" Sent: Wednesday, March 12, 2014 7:27:30 AM Subject: Re: [dba-SQLServer] PK/ANPK Debate On Tue, Mar 11, 2014 at 5:00 PM, Darryl Collins < darryl at whittleconsulting.com.au> wrote: > Bound vs Unbound controls also seems to be a topic that gets folks, > ummm, passionate, about their position I have noted... > only because the bound folks can't disassociate with the the critical requirement in today's world of being disconnected from the datasource for local caching and synching ;-) [granade thrown...] -Francisco _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From accessd at shaw.ca Thu Mar 13 11:34:46 2014 From: accessd at shaw.ca (Jim Lawrence) Date: Thu, 13 Mar 2014 10:34:46 -0600 (MDT) Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: <53216C13.12437.1A80249@stuart.lexacorp.com.pg> Message-ID: <263113895.1920172.1394728486639.JavaMail.root@cds018> Hi Stuart: And that is what limits the size of a pure default Access implementation. Jim ----- Original Message ----- From: "Stuart McLachlan" To: "Discussion concerning MS SQL Server" Sent: Thursday, March 13, 2014 1:28:03 AM Subject: Re: [dba-SQLServer] PK/ANPK Debate Access FE to Access BE - almost total bound. Access FE to SQL Server/MySQL BE - sometimes bound/ sometines unbound depending on the circumstances and the datasets involved. Any other FE to any BE - total unbound. -- Stuart On 13 Mar 2014 at 3:17, Darryl Collins wrote: > Yeah, I would have hoped we have moved on by now. For what it is > worth, I have been firmly in the unbound camp for many years. > > Regards > Darryl. > > > -----Original Message----- > From: dba-sqlserver-bounces at databaseadvisors.com > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim > Lawrence Sent: Thursday, 13 March 2014 11:53 AM To: Discussion > concerning MS SQL Server Subject: Re: [dba-SQLServer] PK/ANPK Debate > > Hi Francisco: > > I think that whole discussion has moved on. I seriously doubt whether > suggesting a "bound" database is even an issue now, is a stretch and > those still supporting it, IMHO, are on pare with members of "The > Fall-Earth Society". The "bound" argument was flimsy even back in the > late nineties or as soon a real ACID databases became the industry > standard...and the realization that there was just not enough > band-width, nodes or servers to support object binding. > > Jim > > ----- Original Message ----- > From: "Francisco Tapia" > To: "Discussion concerning MS SQL Server" > Sent: Wednesday, March 12, 2014 > 7:27:30 AM Subject: Re: [dba-SQLServer] PK/ANPK Debate > > On Tue, Mar 11, 2014 at 5:00 PM, Darryl Collins < > darryl at whittleconsulting.com.au> wrote: > > > Bound vs Unbound controls also seems to be a topic that gets folks, > > ummm, passionate, about their position I have noted... > > > > only because the bound folks can't disassociate with the the critical > requirement in today's world of being disconnected from the datasource > for local caching and synching ;-) > > [granade thrown...] > > > -Francisco > _______________________________________________ dba-SQLServer mailing > list dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From jlawrenc1 at shaw.ca Thu Mar 13 13:02:10 2014 From: jlawrenc1 at shaw.ca (Jim Lawrence) Date: Thu, 13 Mar 2014 12:02:10 -0600 (MDT) Subject: [dba-SQLServer] PK/ANPK Debate In-Reply-To: Message-ID: <1687549782.1994907.1394733730048.JavaMail.root@cds057> Hi Guys: To my understanding the issues around bound and unbound and SQL and NoSQL are basically the same. A bound database was practical and possible when the database or number of users was small but beyond a certain size; in the case of default MS Access, fifty users was pushing it and the ability to maintain such a system was impractical. This is the same with SQL. When the database reaches a certain size or the data reaches a certain level of complexity, the ability to retrieve a specific data set can be very time consuming as the SQL engine is really grinding. SQLs great weakness is the limits on join complexity and the inflexibility of the schema. (I have first hand experience crippling a big Oracle server...) So neither of the bound-unbound or the SQL-NoSQL is wrong but the context in which these methods are used are dictated by the number of users and the amount of data to be managed. Jim PS: Mark I would really like to know all your experiences with MongoDB. As I now have a 64bit server class motherboard with 32GB of RAM and as soon as the server is assembled MongoDB will be one of my first experiments. :-) ----- Original Message ----- From: "Mark Breen" To: "Discussion concerning MS SQL Server" Sent: Wednesday, 12 March, 2014 1:57:25 AM Subject: Re: [dba-SQLServer] PK/ANPK Debate Hello Shamil, yes, I agree completely, this is a much more up to date thread to discuss. I worked on a project last year that had to store thousands or tens of thousands of records. However, they wanted 100% failsafe fail over. They used two mongo dbs and they told me the db's just take care of they syncing. That is interesting to me. Nowadays with hardware so cheap, it is interesting to think that we can have two or three servers running our BE. But as you are hinting at, it is a new mindshift, one that we have to open up to sooner or later, not necessarily to store billions or records, but as a new way to store data. Mark On 12 March 2014 05:25, Salakhetdinov Shamil wrote: > Yes, but here in dba-SQL-Server "SQL Server vs. NoSQL" "holy war" thread > would be more suitable than "Bound vs Unbound controls", should we ask > Arthur to initiate it? ;) > > > Wednesday, March 12, 2014 12:00 AM UTC from Darryl Collins < > darryl at whittleconsulting.com.au>: > >Bound vs Unbound controls also seems to be a topic that gets folks, > ummm, passionate, about their position I have noted... > > > > > > > >-----Original Message----- > >From: dba-sqlserver-bounces at databaseadvisors.com [mailto: > dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francisco Tapia > >Sent: Wednesday, 12 March 2014 6:41 AM > >To: Discussion concerning MS SQL Server > >Subject: Re: [dba-SQLServer] PK/ANPK Debate > > > >On Tue, Mar 11, 2014 at 12:32 PM, Arthur Fuller < fuller.artful at gmail.com>wrote: > > > >> Said mission was not to prove > >> or even posit my point, but to kick the ashes and see whether the > >> embers are still burning. And they are! Nothing like a hot topic to > >> awake the sleeping dragons. > >> > > > >hahaha, you know this topic sparks an un-holy war! XD > > > >It's even more religious than the thou shall not use cursors in your > SQL!!! > >lol > > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From jlawrenc1 at shaw.ca Thu Mar 13 13:04:43 2014 From: jlawrenc1 at shaw.ca (Jim Lawrence) Date: Thu, 13 Mar 2014 12:04:43 -0600 (MDT) Subject: [dba-SQLServer] SQL Server vs. NoSQL In-Reply-To: Message-ID: <57834251.1997154.1394733883709.JavaMail.root@cds057> Good points...Jim ----- Original Message ----- From: "Francisco Tapia" To: "Discussion concerning MS SQL Server" Sent: Wednesday, 12 March, 2014 7:19:04 AM Subject: [dba-SQLServer] SQL Server vs. NoSQL On Tue, Mar 11, 2014 at 10:25 PM, Salakhetdinov Shamil wrote: > Yes, but here in dba-SQL-Server "SQL Server vs. NoSQL" "holy war" thread > would be more suitable than "Bound vs Unbound controls", should we ask > Arthur to initiate it? ;) > I'll kick in with a devil's advocate argument :) The argument for NoSQL are very attractive, speed, and scalability seems to be about the strongest argument. This of course hand in hand with volume of data, but even if you do not have terabytes of data, you can still get solid performance improvements over standard MS SQL Server solutions... I believe that is why the 2014 SQL Server solution will feature in memory tables, it's not noSql, it's more of a "Fusion Drive" for Sql Server, i remember reading in the past as I have not worked with the 2014 CTP version, that stored procedures that reference in memory tables exclusively can be natively compiled which I think makes them faster, but I guess we will see. I like the arguments for NoSQL for speed, and I think this is great as it pushes MS to come up with a new optimized solution. -Francisco _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From jlawrenc1 at shaw.ca Thu Mar 13 13:55:30 2014 From: jlawrenc1 at shaw.ca (Jim Lawrence) Date: Thu, 13 Mar 2014 12:55:30 -0600 (MDT) Subject: [dba-SQLServer] Design first without Id column - was Arthurs thread In-Reply-To: Message-ID: <203478313.2035564.1394736930704.JavaMail.root@cds057> Hi Arthur: After 30+ year, I feel I know less than ever when it comes to the management of data. ;-) I have worked with RDMS databases but now it is time to learn something new...time to add NoSQL skill sets. Pleased to see my old friend TOAD is right there too. http://www.toadworld.com/platforms/nosql/w/wiki/349.mongodb-data-modeling.aspx Jim ----- Original Message ----- From: "Arthur Fuller" To: "Discussion concerning MS SQL Server" Sent: Wednesday, 12 March, 2014 8:06:14 AM Subject: Re: [dba-SQLServer] Design first without Id column - was Arthurs thread Mark et. al. In terms of data-modeling, this describes the difference between Logical and Physical data models. Logical describes a database in terms closer to human than to machine. Physical describes the actual implementation, taking into account such features as Sequences (Oracle for example). Logical describes the domain without regard for which RDMS one ultimately chooses. Tools such as ERWin, PowerDesigner, etc. exist because of this division. At the Logical level, the focus is on the problem or challenge or domain, and good tools free you from commitment to any particular RDMS. We do our design at the LDM level, and only when that level is satisfied (i.e. fully descriptive) do we move to the PDM level, whose choice of RDMS may have absolutely nothing to do with the particular problem (i.e. "We're an Oracle shop and that's that."). I've been in the db game for 3+ decades, and I deem data-modeling tools absolutely vital, even for relatively small apps consisting of say 20 tables or fewer. I've also, in fact more frequently, been on the farther end of the spectrum, designing systems involving 500+ tables; in those situations, you'd have to be either insane or masochistic or some combination of both to try it by hand. A. _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From jnatola at hotmail.com Mon Mar 17 15:29:07 2014 From: jnatola at hotmail.com (J- P) Date: Mon, 17 Mar 2014 16:29:07 -0400 Subject: [dba-SQLServer] sql2005 express to standard Message-ID: Hi all, we have an sql express database that has been running for many many many years, we are getting a new timtrack software that they recommend to run on sql standard, a few vendors still have sql 2005std on hand for a really good price (we need the cpu license) , so the question i have is two-fold; a) is the best way to upgrade the current db to standard via back up /restore? b) is it foolish to purchase sql 2005 given that we are in 2014? Any thoughts/feedback. opinions would be greatly appreciated. TIA From newsgrps at dalyn.co.nz Mon Mar 17 15:33:02 2014 From: newsgrps at dalyn.co.nz (David Emerson) Date: Tue, 18 Mar 2014 09:33:02 +1300 Subject: [dba-SQLServer] Strange Create Table Syntax Message-ID: <003c01cf4220$17dd27b0$47977710$@dalyn.co.nz> Hi Listers, I have been given a script to run to create a set of SQL Tables as follows: CREATE TABLE [dbo].[empabsence]( [emp_num] [dbo].[EmpNumType] NOT NULL, [date_abs] [dbo].[DateType] NOT NULL, [hrs] [dbo].[AbsenceHoursType] NULL CONSTRAINT [DF_empabsence_hrs] DEFAULT ((0)), Etc When I run the script I get an error Msg 2715, Level 16, State 7, Line 1 Column, parameter, or variable #1: Cannot find data type dbo.EmpNumType. I do not have access to the original database so can't do any checking. Where would the dbo.EmpNumType type be created? Regards David Emerson Dalyn Software Ltd Wellington, New Zealand From newsgrps at dalyn.co.nz Mon Mar 17 15:39:20 2014 From: newsgrps at dalyn.co.nz (David Emerson) Date: Tue, 18 Mar 2014 09:39:20 +1300 Subject: [dba-SQLServer] Strange Create Table Syntax In-Reply-To: <003c01cf4220$17dd27b0$47977710$@dalyn.co.nz> References: <003c01cf4220$17dd27b0$47977710$@dalyn.co.nz> Message-ID: <004101cf4220$f927b730$eb772590$@dalyn.co.nz> Never mind - I found the Create Type command. -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of David Emerson Sent: Tuesday, 18 March 2014 9:33 a.m. To: AccessDSQL Subject: [dba-SQLServer] Strange Create Table Syntax Hi Listers, I have been given a script to run to create a set of SQL Tables as follows: CREATE TABLE [dbo].[empabsence]( [emp_num] [dbo].[EmpNumType] NOT NULL, [date_abs] [dbo].[DateType] NOT NULL, [hrs] [dbo].[AbsenceHoursType] NULL CONSTRAINT [DF_empabsence_hrs] DEFAULT ((0)), Etc When I run the script I get an error Msg 2715, Level 16, State 7, Line 1 Column, parameter, or variable #1: Cannot find data type dbo.EmpNumType. I do not have access to the original database so can't do any checking. Where would the dbo.EmpNumType type be created? Regards David Emerson Dalyn Software Ltd Wellington, New Zealand _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com From gustav at cactus.dk Mon Mar 17 16:22:36 2014 From: gustav at cactus.dk (Gustav Brock) Date: Mon, 17 Mar 2014 21:22:36 +0000 Subject: [dba-SQLServer] sql2005 express to standard In-Reply-To: References: Message-ID: <73fe986ca29c49c59f49cc4d5459fa3a@AMSPR06MB311.eurprd06.prod.outlook.com> Hi J-P The big question is what "recommend" means. Does timtrack run on your Express 2005 or not? The newer versions have improved, so what specs of the Standard version will make a difference? /gustav ________________________________________ Fra: dba-sqlserver-bounces at databaseadvisors.com p? vegne af J- P Sendt: 17. marts 2014 21:29 Til: sql list Emne: [dba-SQLServer] sql2005 express to standard Hi all, we have an sql express database that has been running for many many many years, we are getting a new timtrack software that they recommend to run on sql standard, a few vendors still have sql 2005std on hand for a really good price (we need the cpu license) , so the question i have is two-fold; a) is the best way to upgrade the current db to standard via back up /restore? b) is it foolish to purchase sql 2005 given that we are in 2014? Any thoughts/feedback. opinions would be greatly appreciated. TIA From jnatola at hotmail.com Mon Mar 17 20:16:06 2014 From: jnatola at hotmail.com (J- P) Date: Mon, 17 Mar 2014 21:16:06 -0400 Subject: [dba-SQLServer] sql2005 express to standard In-Reply-To: <73fe986ca29c49c59f49cc4d5459fa3a@AMSPR06MB311.eurprd06.prod.outlook.com> References: , <73fe986ca29c49c59f49cc4d5459fa3a@AMSPR06MB311.eurprd06.prod.outlook.com> Message-ID: Ram is the issue , they say you need 1.8 cpu & 2 gigs of RAM, where express only allows 1gb. The other issue is that software is only "officially certified" up to sql 2008r2 , meaning that even if 2012 express? were more efficient its still not "officially supported" Allthough there are aproximtley 200 employees, the normal daily workload (punch in , punch out etc..) will be on the average 40-60 employees, each one punching in & out anywhere from 2 to 4 times a day e.g. a short shift arrival punch in, departure punch out, in contrast a full shift would have; arrival , lunch , departure. On the BUSIEST days of the year maybe, at MOST 120 employees, this only happens maybe 4 or 5 days a year, and one supervisor generating a report, or payroll etc.. The software primary function is; Provides real-time information to help managers control overtime and stay within budget. Automatically creates and distributes employee schedules. An online timesheet for employees, Employee Self Service empowers employees while reducing workload for HR. An online time tracker for supervisors, Manager Self Service lets supervisors track and manage their workforce. Leave management automates employee requests for time away from their work schedules. The software will be linked to the in-house DB so that when a job is spec'd they will have actual labor costs rather than having to make manually enter X= hours for setup, X hours for onsite , X hours for strike etc... If in fact I go the express and for whatever reason it is not handling the load, would the upgrade be a simple backup db from express, restore db to full? thanks again ? > From: gustav at cactus.dk > To: dba-sqlserver at databaseadvisors.com > Date: Mon, 17 Mar 2014 21:22:36 +0000 > Subject: Re: [dba-SQLServer] sql2005 express to standard > > Hi J-P > > The big question is what "recommend" means. > Does timtrack run on your Express 2005 or not? The newer versions have improved, so what specs of the Standard version will make a difference? > > /gustav > > ________________________________________ > Fra: dba-sqlserver-bounces at databaseadvisors.com p? vegne af J- P > Sendt: 17. marts 2014 21:29 > Til: sql list > Emne: [dba-SQLServer] sql2005 express to standard > > Hi all, > > we have an sql express database that has been running for many many many years, we are getting a new timtrack software that they recommend to run on sql standard, a few vendors still have sql 2005std on hand for a really good price (we need the cpu license) , so the question i have is two-fold; > > a) is the best way to upgrade the current db to standard via back up /restore? > > b) is it foolish to purchase sql 2005 given that we are in 2014? > > Any thoughts/feedback. opinions would be greatly appreciated. > > TIA > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > From gustav at cactus.dk Tue Mar 18 02:38:28 2014 From: gustav at cactus.dk (Gustav Brock) Date: Tue, 18 Mar 2014 07:38:28 +0000 Subject: [dba-SQLServer] sql2005 express to standard Message-ID: <19b33df2b9f04523a46881b977e0875a@AMSPR06MB311.eurprd06.prod.outlook.com> Hi J-P Well, the ram limit of 1 GB for the Express version may be a valid point. However, as you describe the load, the server will have a quiet life so I doubt it will represent an issue. It depends if the 1 GB is a requirement or a recommendation. With 200 employees you will be dependent on support, so I would stick with the supported 2008 R2 version for Express. If the vendor still supports 2005, you could safely use a 2005 Standard license. At any time you can move your database from Express to Standard or to at least the next version. I have only done this a couple of times so some with more experience may chime in. /gustav -----Oprindelig meddelelse----- Fra: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af J- P Sendt: 18. marts 2014 02:16 Til: sql list Emne: Re: [dba-SQLServer] sql2005 express to standard Ram is the issue , they say you need 1.8 cpu & 2 gigs of RAM, where express only allows 1gb. The other issue is that software is only "officially certified" up to sql 2008r2 , meaning that even if 2012 express? were more efficient its still not "officially supported" Allthough there are aproximtley 200 employees, the normal daily workload (punch in , punch out etc..) will be on the average 40-60 employees, each one punching in & out anywhere from 2 to 4 times a day e.g. a short shift arrival punch in, departure punch out, in contrast a full shift would have; arrival , lunch , departure. On the BUSIEST days of the year maybe, at MOST 120 employees, this only happens maybe 4 or 5 days a year, and one supervisor generating a report, or payroll etc.. The software primary function is; Provides real-time information to help managers control overtime and stay within budget. Automatically creates and distributes employee schedules. An online timesheet for employees, Employee Self Service empowers employees while reducing workload for HR. An online time tracker for supervisors, Manager Self Service lets supervisors track and manage their workforce. Leave management automates employee requests for time away from their work schedules. The software will be linked to the in-house DB so that when a job is spec'd they will have actual labor costs rather than having to make manually enter X= hours for setup, X hours for onsite , X hours for strike etc... If in fact I go the express and for whatever reason it is not handling the load, would the upgrade be a simple backup db from express, restore db to full? thanks again > From: gustav at cactus.dk > To: dba-sqlserver at databaseadvisors.com > Date: Mon, 17 Mar 2014 21:22:36 +0000 > Subject: Re: [dba-SQLServer] sql2005 express to standard > > Hi J-P > > The big question is what "recommend" means. > Does timtrack run on your Express 2005 or not? The newer versions have improved, so what specs of the Standard version will make a difference? > > /gustav > > ________________________________________ > Fra: dba-sqlserver-bounces at databaseadvisors.com p? vegne af J- P > Sendt: 17. marts 2014 21:29 > Til: sql list > Emne: [dba-SQLServer] sql2005 express to standard > > Hi all, > > we have an sql express database that has been running for many many many years, we are getting a new timtrack software that they recommend to run on sql standard, a few vendors still have sql 2005std on hand for a really good price (we need the cpu license) , so the question i have is two-fold; > > a) is the best way to upgrade the current db to standard via back up /restore? > > b) is it foolish to purchase sql 2005 given that we are in 2014? > > Any thoughts/feedback. opinions would be greatly appreciated. > > TIA From paul.hartland at googlemail.com Tue Mar 18 03:10:14 2014 From: paul.hartland at googlemail.com (Paul Hartland) Date: Tue, 18 Mar 2014 08:10:14 +0000 Subject: [dba-SQLServer] sql2005 express to standard In-Reply-To: References: Message-ID: I have always been the if not broke don't fix it guy (with a few exceptions), if 2005 works for you why change it, also if you remove the management studio before upgrading (not re-installing) to SQL Server 2005 standard, it "should" go without a hitch, without the need to backup/restore or detach/attach the databases and the server instance should remain the same. Paul On 17 March 2014 20:29, J- P wrote: > Hi all, > > we have an sql express database that has been running for many many many > years, we are getting a new timtrack software that they recommend to run on > sql standard, a few vendors still have sql 2005std on hand for a really > good price (we need the cpu license) , so the question i have is two-fold; > > a) is the best way to upgrade the current db to standard via back up > /restore? > > b) is it foolish to purchase sql 2005 given that we are in 2014? > > Any thoughts/feedback. opinions would be greatly appreciated. > > TIA > > > > > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- Paul Hartland paul.hartland at googlemail.com From jnatola at hotmail.com Tue Mar 18 10:03:22 2014 From: jnatola at hotmail.com (J- P) Date: Tue, 18 Mar 2014 11:03:22 -0400 Subject: [dba-SQLServer] sql2005 express to standard In-Reply-To: References: , Message-ID: My only hesitation about purchasing 2005 std is the fact that its approaching MS EOL > Date: Tue, 18 Mar 2014 08:10:14 +0000 > From: paul.hartland at googlemail.com > To: dba-sqlserver at databaseadvisors.com > Subject: Re: [dba-SQLServer] sql2005 express to standard > > I have always been the if not broke don't fix it guy (with a few > exceptions), if 2005 works for you why change it, also if you remove the > management studio before upgrading (not re-installing) to SQL Server 2005 > standard, it "should" go without a hitch, without the need to > backup/restore or detach/attach the databases and the server instance > should remain the same. > > Paul > > > On 17 March 2014 20:29, J- P wrote: > > > Hi all, > > > > we have an sql express database that has been running for many many many > > years, we are getting a new timtrack software that they recommend to run on > > sql standard, a few vendors still have sql 2005std on hand for a really > > good price (we need the cpu license) , so the question i have is two-fold; > > > > a) is the best way to upgrade the current db to standard via back up > > /restore? > > > > b) is it foolish to purchase sql 2005 given that we are in 2014? > > > > Any thoughts/feedback. opinions would be greatly appreciated. > > > > TIA > > > > > > > > > > > > > > > > _______________________________________________ > > dba-SQLServer mailing list > > dba-SQLServer at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > http://www.databaseadvisors.com > > > > > > > -- > Paul Hartland > paul.hartland at googlemail.com > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > From paul.hartland at googlemail.com Tue Mar 18 10:29:05 2014 From: paul.hartland at googlemail.com (Paul Hartland) Date: Tue, 18 Mar 2014 15:29:05 +0000 Subject: [dba-SQLServer] sql2005 express to standard In-Reply-To: References: Message-ID: Well then it comes down to cost and whether you or your company take the chance on support ending and something going wrong, I had little involvement with my two previous companies about the versions we installed. In this case I would probably go the to company supplying the timtrack software and ask them about newer express versions first, maybe SQL Express 2012 Advanced maybe an option or why they recommend going to a standard edition i.e. why do they say this, if it's the size of the databases 2012 and (i think) 2008 upwards can support 10GB databases. Then when you get the answers from them, put that along together with costs, pro's and con's for your company and see what they say, or when you find out why your timtrack supplier recommends standard editions, post back on here, just because a company recommends it, doesn't mean it won't work with an express version. Paul On 18 March 2014 15:03, J- P wrote: > My only hesitation about purchasing 2005 std is the fact that its > approaching MS EOL > > > Date: Tue, 18 Mar 2014 08:10:14 +0000 > > From: paul.hartland at googlemail.com > > To: dba-sqlserver at databaseadvisors.com > > Subject: Re: [dba-SQLServer] sql2005 express to standard > > > > I have always been the if not broke don't fix it guy (with a few > > exceptions), if 2005 works for you why change it, also if you remove the > > management studio before upgrading (not re-installing) to SQL Server 2005 > > standard, it "should" go without a hitch, without the need to > > backup/restore or detach/attach the databases and the server instance > > should remain the same. > > > > Paul > > > > > > On 17 March 2014 20:29, J- P wrote: > > > > > Hi all, > > > > > > we have an sql express database that has been running for many many > many > > > years, we are getting a new timtrack software that they recommend to > run on > > > sql standard, a few vendors still have sql 2005std on hand for a really > > > good price (we need the cpu license) , so the question i have is > two-fold; > > > > > > a) is the best way to upgrade the current db to standard via back up > > > /restore? > > > > > > b) is it foolish to purchase sql 2005 given that we are in 2014? > > > > > > Any thoughts/feedback. opinions would be greatly appreciated. > > > > > > TIA > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > dba-SQLServer mailing list > > > dba-SQLServer at databaseadvisors.com > > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > > http://www.databaseadvisors.com > > > > > > > > > > > > -- > > Paul Hartland > > paul.hartland at googlemail.com > > _______________________________________________ > > dba-SQLServer mailing list > > dba-SQLServer at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > http://www.databaseadvisors.com > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- Paul Hartland paul.hartland at googlemail.com From paul.hartland at googlemail.com Tue Mar 18 10:35:53 2014 From: paul.hartland at googlemail.com (Paul Hartland) Date: Tue, 18 Mar 2014 15:35:53 +0000 Subject: [dba-SQLServer] sql2005 express to standard In-Reply-To: References: Message-ID: Another thought this timtrack software has the deal been done etc, if not is there a similar product that could be brought in that would run on SQL Express versions, what does this timtrack software do ?, could something similar be written in-house or out-sourced to provide a cheaper option in the long run ? Paul On 18 March 2014 15:03, J- P wrote: > My only hesitation about purchasing 2005 std is the fact that its > approaching MS EOL > > > Date: Tue, 18 Mar 2014 08:10:14 +0000 > > From: paul.hartland at googlemail.com > > To: dba-sqlserver at databaseadvisors.com > > Subject: Re: [dba-SQLServer] sql2005 express to standard > > > > I have always been the if not broke don't fix it guy (with a few > > exceptions), if 2005 works for you why change it, also if you remove the > > management studio before upgrading (not re-installing) to SQL Server 2005 > > standard, it "should" go without a hitch, without the need to > > backup/restore or detach/attach the databases and the server instance > > should remain the same. > > > > Paul > > > > > > On 17 March 2014 20:29, J- P wrote: > > > > > Hi all, > > > > > > we have an sql express database that has been running for many many > many > > > years, we are getting a new timtrack software that they recommend to > run on > > > sql standard, a few vendors still have sql 2005std on hand for a really > > > good price (we need the cpu license) , so the question i have is > two-fold; > > > > > > a) is the best way to upgrade the current db to standard via back up > > > /restore? > > > > > > b) is it foolish to purchase sql 2005 given that we are in 2014? > > > > > > Any thoughts/feedback. opinions would be greatly appreciated. > > > > > > TIA > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > dba-SQLServer mailing list > > > dba-SQLServer at databaseadvisors.com > > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > > http://www.databaseadvisors.com > > > > > > > > > > > > -- > > Paul Hartland > > paul.hartland at googlemail.com > > _______________________________________________ > > dba-SQLServer mailing list > > dba-SQLServer at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > http://www.databaseadvisors.com > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- Paul Hartland paul.hartland at googlemail.com From jnatola at hotmail.com Tue Mar 18 11:05:08 2014 From: jnatola at hotmail.com (J- P) Date: Tue, 18 Mar 2014 12:05:08 -0400 Subject: [dba-SQLServer] sql2005 express to standard In-Reply-To: References: , , , Message-ID: the main/only reason is the RAM, database size is not an issue I am going to have a teleconference with them at some point this week. I think they may be saying that in order to cover their rears should express not handle it well. Jean-Paul Natola > Date: Tue, 18 Mar 2014 15:29:05 +0000 > From: paul.hartland at googlemail.com > To: dba-sqlserver at databaseadvisors.com > Subject: Re: [dba-SQLServer] sql2005 express to standard > > Well then it comes down to cost and whether you or your company take the > chance on support ending and something going wrong, I had little > involvement with my two previous companies about the versions we installed. > In this case I would probably go the to company supplying the timtrack > software and ask them about newer express versions first, maybe SQL Express > 2012 Advanced maybe an option or why they recommend going to a standard > edition i.e. why do they say this, if it's the size of the databases 2012 > and (i think) 2008 upwards can support 10GB databases. Then when you get > the answers from them, put that along together with costs, pro's and con's > for your company and see what they say, or when you find out why your > timtrack supplier recommends standard editions, post back on here, just > because a company recommends it, doesn't mean it won't work with an express > version. > > Paul > > > On 18 March 2014 15:03, J- P wrote: > > > My only hesitation about purchasing 2005 std is the fact that its > > approaching MS EOL > > > > > Date: Tue, 18 Mar 2014 08:10:14 +0000 > > > From: paul.hartland at googlemail.com > > > To: dba-sqlserver at databaseadvisors.com > > > Subject: Re: [dba-SQLServer] sql2005 express to standard > > > > > > I have always been the if not broke don't fix it guy (with a few > > > exceptions), if 2005 works for you why change it, also if you remove the > > > management studio before upgrading (not re-installing) to SQL Server 2005 > > > standard, it "should" go without a hitch, without the need to > > > backup/restore or detach/attach the databases and the server instance > > > should remain the same. > > > > > > Paul > > > > > > > > > On 17 March 2014 20:29, J- P wrote: > > > > > > > Hi all, > > > > > > > > we have an sql express database that has been running for many many > > many > > > > years, we are getting a new timtrack software that they recommend to > > run on > > > > sql standard, a few vendors still have sql 2005std on hand for a really > > > > good price (we need the cpu license) , so the question i have is > > two-fold; > > > > > > > > a) is the best way to upgrade the current db to standard via back up > > > > /restore? > > > > > > > > b) is it foolish to purchase sql 2005 given that we are in 2014? > > > > > > > > Any thoughts/feedback. opinions would be greatly appreciated. > > > > > > > > TIA > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > dba-SQLServer mailing list > > > > dba-SQLServer at databaseadvisors.com > > > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > > > http://www.databaseadvisors.com > > > > > > > > > > > > > > > > > -- > > > Paul Hartland > > > paul.hartland at googlemail.com > > > _______________________________________________ > > > dba-SQLServer mailing list > > > dba-SQLServer at databaseadvisors.com > > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > > http://www.databaseadvisors.com > > > > > > > _______________________________________________ > > dba-SQLServer mailing list > > dba-SQLServer at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > http://www.databaseadvisors.com > > > > > > > -- > Paul Hartland > paul.hartland at googlemail.com > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > From paul.hartland at googlemail.com Tue Mar 18 11:12:30 2014 From: paul.hartland at googlemail.com (Paul Hartland) Date: Tue, 18 Mar 2014 16:12:30 +0000 Subject: [dba-SQLServer] sql2005 express to standard In-Reply-To: References: Message-ID: hmmm yes could be an issue, Im sure someone will correct me if I am wrong but I think all the express editions utilise a maximum of about 1GB. On 18 March 2014 16:05, J- P wrote: > the main/only reason is the RAM, database size is not an issue I am going > to have a teleconference with them at some point this week. > > I think they may be saying that in order to cover their rears should > express not handle it well. > > > > Jean-Paul Natola > > > > > > Date: Tue, 18 Mar 2014 15:29:05 +0000 > > From: paul.hartland at googlemail.com > > To: dba-sqlserver at databaseadvisors.com > > Subject: Re: [dba-SQLServer] sql2005 express to standard > > > > Well then it comes down to cost and whether you or your company take the > > chance on support ending and something going wrong, I had little > > involvement with my two previous companies about the versions we > installed. > > In this case I would probably go the to company supplying the timtrack > > software and ask them about newer express versions first, maybe SQL > Express > > 2012 Advanced maybe an option or why they recommend going to a standard > > edition i.e. why do they say this, if it's the size of the databases 2012 > > and (i think) 2008 upwards can support 10GB databases. Then when you get > > the answers from them, put that along together with costs, pro's and > con's > > for your company and see what they say, or when you find out why your > > timtrack supplier recommends standard editions, post back on here, just > > because a company recommends it, doesn't mean it won't work with an > express > > version. > > > > Paul > > > > > > On 18 March 2014 15:03, J- P wrote: > > > > > My only hesitation about purchasing 2005 std is the fact that its > > > approaching MS EOL > > > > > > > Date: Tue, 18 Mar 2014 08:10:14 +0000 > > > > From: paul.hartland at googlemail.com > > > > To: dba-sqlserver at databaseadvisors.com > > > > Subject: Re: [dba-SQLServer] sql2005 express to standard > > > > > > > > I have always been the if not broke don't fix it guy (with a few > > > > exceptions), if 2005 works for you why change it, also if you remove > the > > > > management studio before upgrading (not re-installing) to SQL Server > 2005 > > > > standard, it "should" go without a hitch, without the need to > > > > backup/restore or detach/attach the databases and the server instance > > > > should remain the same. > > > > > > > > Paul > > > > > > > > > > > > On 17 March 2014 20:29, J- P wrote: > > > > > > > > > Hi all, > > > > > > > > > > we have an sql express database that has been running for many > many > > > many > > > > > years, we are getting a new timtrack software that they recommend > to > > > run on > > > > > sql standard, a few vendors still have sql 2005std on hand for a > really > > > > > good price (we need the cpu license) , so the question i have is > > > two-fold; > > > > > > > > > > a) is the best way to upgrade the current db to standard via back > up > > > > > /restore? > > > > > > > > > > b) is it foolish to purchase sql 2005 given that we are in 2014? > > > > > > > > > > Any thoughts/feedback. opinions would be greatly appreciated. > > > > > > > > > > TIA > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > dba-SQLServer mailing list > > > > > dba-SQLServer at databaseadvisors.com > > > > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > > > > http://www.databaseadvisors.com > > > > > > > > > > > > > > > > > > > > > > -- > > > > Paul Hartland > > > > paul.hartland at googlemail.com > > > > _______________________________________________ > > > > dba-SQLServer mailing list > > > > dba-SQLServer at databaseadvisors.com > > > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > > > http://www.databaseadvisors.com > > > > > > > > > > _______________________________________________ > > > dba-SQLServer mailing list > > > dba-SQLServer at databaseadvisors.com > > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > > http://www.databaseadvisors.com > > > > > > > > > > > > -- > > Paul Hartland > > paul.hartland at googlemail.com > > _______________________________________________ > > dba-SQLServer mailing list > > dba-SQLServer at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > http://www.databaseadvisors.com > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > -- Paul Hartland paul.hartland at googlemail.com From jnatola at hotmail.com Tue Mar 18 11:14:06 2014 From: jnatola at hotmail.com (J- P) Date: Tue, 18 Mar 2014 12:14:06 -0400 Subject: [dba-SQLServer] sql2005 express to standard In-Reply-To: References: , , , , , Message-ID: yes, all express are limited to 1GB per database > Date: Tue, 18 Mar 2014 16:12:30 +0000 > From: paul.hartland at googlemail.com > To: dba-sqlserver at databaseadvisors.com > Subject: Re: [dba-SQLServer] sql2005 express to standard > > hmmm yes could be an issue, Im sure someone will correct me if I am wrong > but I think all the express editions utilise a maximum of about 1GB. > > > On 18 March 2014 16:05, J- P wrote: > > > the main/only reason is the RAM, database size is not an issue I am going > > to have a teleconference with them at some point this week. > > > > I think they may be saying that in order to cover their rears should > > express not handle it well. > > > > > > > > Jean-Paul Natola > > > > > > > > > > > Date: Tue, 18 Mar 2014 15:29:05 +0000 > > > From: paul.hartland at googlemail.com > > > To: dba-sqlserver at databaseadvisors.com > > > Subject: Re: [dba-SQLServer] sql2005 express to standard > > > > > > Well then it comes down to cost and whether you or your company take the > > > chance on support ending and something going wrong, I had little > > > involvement with my two previous companies about the versions we > > installed. > > > In this case I would probably go the to company supplying the timtrack > > > software and ask them about newer express versions first, maybe SQL > > Express > > > 2012 Advanced maybe an option or why they recommend going to a standard > > > edition i.e. why do they say this, if it's the size of the databases 2012 > > > and (i think) 2008 upwards can support 10GB databases. Then when you get > > > the answers from them, put that along together with costs, pro's and > > con's > > > for your company and see what they say, or when you find out why your > > > timtrack supplier recommends standard editions, post back on here, just > > > because a company recommends it, doesn't mean it won't work with an > > express > > > version. > > > > > > Paul > > > > > > > > > On 18 March 2014 15:03, J- P wrote: > > > > > > > My only hesitation about purchasing 2005 std is the fact that its > > > > approaching MS EOL > > > > > > > > > Date: Tue, 18 Mar 2014 08:10:14 +0000 > > > > > From: paul.hartland at googlemail.com > > > > > To: dba-sqlserver at databaseadvisors.com > > > > > Subject: Re: [dba-SQLServer] sql2005 express to standard > > > > > > > > > > I have always been the if not broke don't fix it guy (with a few > > > > > exceptions), if 2005 works for you why change it, also if you remove > > the > > > > > management studio before upgrading (not re-installing) to SQL Server > > 2005 > > > > > standard, it "should" go without a hitch, without the need to > > > > > backup/restore or detach/attach the databases and the server instance > > > > > should remain the same. > > > > > > > > > > Paul > > > > > > > > > > > > > > > On 17 March 2014 20:29, J- P wrote: > > > > > > > > > > > Hi all, > > > > > > > > > > > > we have an sql express database that has been running for many > > many > > > > many > > > > > > years, we are getting a new timtrack software that they recommend > > to > > > > run on > > > > > > sql standard, a few vendors still have sql 2005std on hand for a > > really > > > > > > good price (we need the cpu license) , so the question i have is > > > > two-fold; > > > > > > > > > > > > a) is the best way to upgrade the current db to standard via back > > up > > > > > > /restore? > > > > > > > > > > > > b) is it foolish to purchase sql 2005 given that we are in 2014? > > > > > > > > > > > > Any thoughts/feedback. opinions would be greatly appreciated. > > > > > > > > > > > > TIA > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > dba-SQLServer mailing list > > > > > > dba-SQLServer at databaseadvisors.com > > > > > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > > > > > http://www.databaseadvisors.com > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Paul Hartland > > > > > paul.hartland at googlemail.com > > > > > _______________________________________________ > > > > > dba-SQLServer mailing list > > > > > dba-SQLServer at databaseadvisors.com > > > > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > > > > http://www.databaseadvisors.com > > > > > > > > > > > > > _______________________________________________ > > > > dba-SQLServer mailing list > > > > dba-SQLServer at databaseadvisors.com > > > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > > > http://www.databaseadvisors.com > > > > > > > > > > > > > > > > > -- > > > Paul Hartland > > > paul.hartland at googlemail.com > > > _______________________________________________ > > > dba-SQLServer mailing list > > > dba-SQLServer at databaseadvisors.com > > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > > http://www.databaseadvisors.com > > > > > > > _______________________________________________ > > dba-SQLServer mailing list > > dba-SQLServer at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > http://www.databaseadvisors.com > > > > > > > -- > Paul Hartland > paul.hartland at googlemail.com > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > From newsgrps at dalyn.co.nz Tue Mar 25 21:38:37 2014 From: newsgrps at dalyn.co.nz (David Emerson) Date: Wed, 26 Mar 2014 15:38:37 +1300 Subject: [dba-SQLServer] SQL Backup and Restore Considerations Message-ID: <004c01cf489c$7def3340$79cd99c0$@dalyn.co.nz> Listers, I have a client that wants to use transaction logs to back up data so that they can recover everything (not just the last 5 minutes) that was entered prior to a system meltdown. Are the different methods of backup and restore in SQL 2008 able to be changed after the database has been initially created or is the method locked down as part of the database creation process? Regards David Emerson Dalyn Software Ltd Wellington, New Zealand From fhtapia at gmail.com Tue Mar 25 22:12:51 2014 From: fhtapia at gmail.com (Francisco Tapia) Date: Tue, 25 Mar 2014 20:12:51 -0700 (PDT) Subject: [dba-SQLServer] SQL Backup and Restore Considerations In-Reply-To: <004c01cf489c$7def3340$79cd99c0$@dalyn.co.nz> References: <004c01cf489c$7def3340$79cd99c0$@dalyn.co.nz> Message-ID: <1395803571542.f29465dd@Nodemailer> Shameless plug http://sqlthis.blogspot.com/2008/06/change-your-recovery-model.html ? Sent from Mailbox for iPhone On Tue, Mar 25, 2014 at 7:40 PM, David Emerson wrote: > Listers, > > I have a client that wants to use transaction logs to back up data so that > they can recover everything (not just the last 5 minutes) that was entered > prior to a system meltdown. > > Are the different methods of backup and restore in SQL 2008 able to be > changed after the database has been initially created or is the method > locked down as part of the database creation process? > > Regards > David Emerson > Dalyn Software Ltd > Wellington, New Zealand > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com From newsgrps at dalyn.co.nz Tue Mar 25 22:37:46 2014 From: newsgrps at dalyn.co.nz (David Emerson) Date: Wed, 26 Mar 2014 16:37:46 +1300 Subject: [dba-SQLServer] SQL Backup and Restore Considerations In-Reply-To: <1395803571542.f29465dd@Nodemailer> References: <004c01cf489c$7def3340$79cd99c0$@dalyn.co.nz> <1395803571542.f29465dd@Nodemailer> Message-ID: <005b01cf48a4$c134e7a0$439eb6e0$@dalyn.co.nz> Thanks for the clear description. David -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francisco Tapia Sent: Wednesday, 26 March 2014 4:13 p.m. To: Discussion concerning MS SQL Server Cc: AccessDSQL Subject: Re: [dba-SQLServer] SQL Backup and Restore Considerations Shameless plug http://sqlthis.blogspot.com/2008/06/change-your-recovery-model.html Sent from Mailbox for iPhone On Tue, Mar 25, 2014 at 7:40 PM, David Emerson wrote: > Listers, > > I have a client that wants to use transaction logs to back up data so > that they can recover everything (not just the last 5 minutes) that > was entered prior to a system meltdown. > > Are the different methods of backup and restore in SQL 2008 able to be > changed after the database has been initially created or is the method > locked down as part of the database creation process? > > Regards > David Emerson > Dalyn Software Ltd > Wellington, New Zealand > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com