January 29, 2009 at 6:20 pm
Oracle does not sell developer edition so it limits what I can do with it in SQL Server there are things I do with it that Microsoft did not say you can do. I started teaching developers to automate data with the then redistributable DTS, in 2005 Microsoft made SSIS none redist and changed automate permissions with Oracle, DB2 and other RDBMS. I have used it and helped many developers it works like a charm now Microsoft actually provide connectors to DB2 and Oracle developers create solutions there are many thing you can do that Microsoft will not tell you.
Installations 2005 comes with a lot of improvement and please don't remind me of the one week I lost in 2005 trying to install Oracle 10g RC2 it blcked my production 9i connection I don't think I could have resolved it without a metalink account.
Kind regards,
Gift Peddie
January 29, 2009 at 9:52 pm
Gift Peddie (1/29/2009)
Oracle does not sell developer edition...
Correct... instead, they give it away as a free download. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
February 5, 2009 at 4:43 pm
I use a desk top operating system so I have to use personal and I don't think I can compare that to SQL Server developer's edition.
Microsoft wants us to tell them we can use Proclarity better than Sharepoint developers. The Visual Studio team editions can use Proclarity and automated ETL packages. So here is the call from Microsoft.
This study starts on February 6 and runs till July 31. It will be a remote study and is open to all U.S.-based participants. We are looking for developers who are familiar with ETL, data warehousing, OLAP cubes, and MDX. We will be offering all participants a gratuity option in appreciation of your time. If you are interested in participating in this study please e-mail us at itusable@microsoft.com with "BI Developer" in the subject line.
Kind regards,
Gift Peddie
June 23, 2009 at 12:00 pm
I'm coming rather late to this, most of my desired enhancements have already been mentioned and about those I'll say no more than that I agre with everything Jeff M said and also share the desire for extra aggregates and for statistical functions (including a range of PRNGs with various distributions) and would add to that the ability to import from real (hardware) RNG.
I agree too with comments to the effect that SQLS is extremely good at basic RDB functionality - I started on Ingres and then used Oracle (including OPS - I even specified a DLM for that) and Postgres before SQL server existed; I gained enough knowledge of DB2 to throw it out of one R&D shop because it took far too long to develop anything serious with it and documentation and support were frankly appalling. Definitely SQLS is better than the other RDBs I have used.
There are a couple of places where SQLS could usefully gain new features though. The first is cross-table existence check constraints; now there is already a sort of cross-table existence check : the foreign key constraint - but that only works if the target is (a) unique and (b) the primary key. Now that's a pity: One kind of data data I work with is text, multiple instances of the "same" text in different languages. The text identifier is NOT unique in a given text table (the primary key is on languageID,textID which gives me nice locality for any given language) nor do all texts have to exist in all languages ( (a) because different customers will use different subsets of the available texts and (b) because there are some things you just don't translate - the "foreign" term is used everywhere, although the orthography may still require you to transliterate), I want to know that all references to texts which occur in other tables (these are by textID only - since we don't know in advance which language is going to be used on any particular occasion, the same referring row being used in conjunction with many different languages) have corresponding items in the relevant text table. Could do that check with a trigger - would rather do it be declaring a constraint.
The second is a closely related one: in SQLS 2000 at least (I haven't checked whether this changed later, since our stuff still has to rubn on SQLS 2000 unless we make existing customers pay for an upgrade) the target of foreign key has to be a single column - so any table whose primary key is multiple columns can't be the target of a foreign key constraint - so I can't check referential integrity in those cases. Of course I could invent an extra table to hold just the key columns of the target table and a unique column, and let the soyrce table refer to that - but that just adds non-useful joins, and i will now have a table that doesn't represent anything real (if for example one of the columns in the primary key was in fact unique and the other columns were included in the primary key to make the primary key index cover them as well as the unique column). (You'll probably gather from this that I've had my fingers singed by excessive normalisation in the past).
The third is another related one: cross-database foreign keys.
The fourth is also related: more flexibility in check constraints - checks that involve aggregates; perhaps checks involve columns in another table (row selected by reference supported by a foreign key constraint).
The fifth is explicit recognition at the language level of chunking - where a large operation is split into several smaller bites because the large operation would otherwise have some undesirable impact. The need for this has been greatly reduced by two improvements in SQLS 2008 (snapshot isolation level; alternate version of read committed isolation level) but it hasn't been eliminated.
The sixth and last is optional transaction restart after deadlock instead of signaling an error to the user process, with victim selection designed to guarantee that every transaction will make progress eventually. It seems very strange that this doesn't appear to be in SQLS 2000 - it was already old hat by the time SQLS 2000 was released (indeed it was already old hat when I was spending time on distributed RDBMS isolation and concurrency control, and that was at least 10 years before SQLS 2000 appeared).
Maybe a distributed parallelism version of SQL server could be useful too - but a desktop PC is easily as powerful as the 256 server parallel system I knew and loved in the old days, so maybe there's not much point.
Tom
June 23, 2009 at 6:24 pm
Tom.Thomson (6/23/2009)
the foreign key constraint - but that only works if the target is (a) unique and (b) the primary key.
I'm pretty sure that only half of that is true. The target doen't have to be the primary key. It only needs to be governed by a unique key and can be more than 1 column. Of course, no one should simply take anyone's word on such a thing. Here's what's listed in Books Online under create table...
FOREIGN KEY...REFERENCES
Is a constraint that provides referential integrity for the data in the column or columns. FOREIGN KEY constraints require that each value in the column exists in the corresponding referenced column(s) in the referenced table. FOREIGN KEY constraints can reference only columns that are PRIMARY KEY or UNIQUE constraints in the referenced table or columns referenced in a UNIQUE INDEX on the referenced table.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 26, 2009 at 5:11 am
Jeff Moden (6/23/2009)
Tom.Thomson (6/23/2009)
the foreign key constraint - but that only works if the target is (a) unique and (b) the primary key.I'm pretty sure that only half of that is true. The target doen't have to be the primary key. It only needs to be governed by a unique key and can be more than 1 column. Of course, no one should simply take anyone's word on such a thing. Here's what's listed in Books Online under create table...
FOREIGN KEY...REFERENCES
Is a constraint that provides referential integrity for the data in the column or columns. FOREIGN KEY constraints require that each value in the column exists in the corresponding referenced column(s) in the referenced table. FOREIGN KEY constraints can reference only columns that are PRIMARY KEY or UNIQUE constraints in the referenced table or columns referenced in a UNIQUE INDEX on the referenced table.
You're right that it doesn't have to be the primary key - I was being sloppy there, must have been having a bad day, I haven't a clue why I wrote it like that because I know that the real rule is that it has to be the subject of an unique constraint (including one implied by a primary key constraint or an unique index). You are right about multiple columns too - I've apparently been carrying some real disinformation in my head for nearly a decade, it must have been some other RDBMS that had the single column restriction! The underlying problem still remains though - cross table existence checks have to be done using triggers, not constraints, unless the target is unique, and it would be useful to fix that. Probably not something that should be done by extending referential integrity constraints - just think what chaos there could be with ON UPDATE CASCADE - but rather with a new type of constraint. Of course in order to avoid having too much computation in evaluating the constraint it would be sensible to require the column list to be an initial subset of the list for an index on the target table.
Tom
June 26, 2009 at 6:17 am
Heh... not to worry, Tom. We've all gotten versions and products confused at one time or another. Thanks for the feedback.
The underlying problem still remains though - cross table existence checks have to be done using triggers, not constraints, unless the target is unique
Jut a bit of a side bar, that would seem to violate the idea of proper normalization.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 7 posts - 76 through 81 (of 81 total)
You must be logged in to reply to this topic. Login to reply