Sucked
- Häagen-Dazs Crisis -- there was never enough. If you've ever wandered
what would happen if your crossed humans with piranha, wonder no more. Just
put a couple of boxes of these out. Gone on six seconds.
- Exhibit hall hours -- pathetic, just pathetic. If I were a vendor, I'd
want my money back.
- RIO area location -- ugh, walking a quarter mile for this was insane.
Ruled
- The Cabanas -- with out a doubt, the place to hang out and see the
coolest stuff and meet people. I hope this idea sticks.
- The Sessions -- I didn't attend a bad one and managed to learn quite a
bit from them. Most f them were excellent.
- The Human Networking -- meet a ton of people that I've never known or
have just
- The Food -- Plenty of it (other than the item noted above) and thank
for, lunch room cops, for being much more relaxed about where people to sit
where they were comfortable for the most part.
I'll give this two thumbs up.
If there was any one session that I felt was must see, its this one.
- XML makes sense to data exchange
- Useful for content management
- Messaging, especially SOAP
- Query status quo
- XPath, mainly navigational, but no reshaping
- Limited data types
- XSLT mainly used for data-driven transformation of XML
- Need a good query and transform
- XQuery: functional, declarative query language
- Provides Xpath and construction
- Can work on typed or untyped data
- Been in the works since 1998.
- The last call working graph is out
- Working is going on full text index. Out of scope for Yukon due to dates
- End of 2005, XQuery in recommendation (no full text nor DML)
- Gave a simple example
- Talked about FLWOR
- Includes XPATH, which is mostly a subset of XQuery
- Order-preserving operators
- XQuery in Yukon will be statically type, strongly typed if schema is
available.
- Schema provides rich structural and provides for the validation of the
query
- XML data modification
- After execuation, you expect consistent results
- Insert might insert anywhere, so a before and after option is
provided
- Delete works on any number of matching nodes, inserts must be
singletons
- Replace is supported too, but must be statically associated with a
single node.
- Showed an example of fetching out the schema that had been shredded and
associated with the column
- Demo of doing an count with XQuery
- .Query method always returns an unbound XML type
- Example of validation from schema. That is very helpful
- Demo of using sql:query and sql:variable and nodes
- Example of using the nodes methods to shred XML in a typed column.
- The name of output tables may be confusing at first
- Talked about modification with the modify method
- It would be easy to get tripped up by the insert behavior if you schema
wanted the node being inserted at a specific location, which will usually be
the case.
- Beta2 is aligned with XQuery Nov. 2003 Last Call Draft
- Added XML Data Modification
- Appled to a single XML data type instance
- For XQuery values, the result must be statically a signleton. SQL type
has to be scalar
- Query generates entitized results.
- No sql:column or sql:variable on XML or CLR UDT types
- Implementation subset
- No let
- No user defined functions
- No XQuery validation
- No expression on constructed nodes
- Dynamic errors are mapped to an empty sequences
- No XQuery joins across differnt XML, but might be able to do this on
the client side
- Exploit type information and use indexeds. Use Xquery for property
promotion.
- Use cast to resolve static type errors
Arpan takes over and talks about XQuery in the framework
- Based on November 2003 XQuery last class
- XQuery and compiles down to MSIL (like XSLT)
- Can use information for XmlSchemaSet
- Can embedded T-SQL in client side code
- You can write additional functionality too
- XML 1.0 can be consumed, as can XMLReader API (XML InfoSet) and
XPathNavigator
- Demos of making dynamic SQL and stored procedure calls
- Demo of calling a Web Service
- DO NOT EXECUTE YOUR JOINS ON THE CLIENT
- Client-side processing exists for legacy stored procedures to XML format
- They've given on rewriting the query when called
Great question, More people needed to be here to start grokking this.
Good to see many people attending considering when the session this session
happened.
- Service broker is a platform for building asynch, queued database
application
- Queue are first class database objects, which the queue operations
expressed in TSQL. Message processing is transactional. All this leads to
reliable distributed queuing
- Asynch provides loose coupling, better performance, load distribution,
batch processing and scale out.
- Demonstrated HelloWorld with a SvcBroker app written in T-SQL.
- Queued apps are hard to write because
- Message Integrity -- you have to know it was transmitted and
received.
- Queueing is important
- Good example of parent-child queuing
- Talked about the dialog protocol -- there will be authentication and
encryption support
- Doesn't use SSL, nor is the destination encrypted for efficiency
reasons
- Messaging is itself is hard
- Writing queues are hard
- Why do messaging in the database?
- Integrated API for the message and the data
- Integrated management, deployment and operations
- Better performance in many cases
- Different features than what is in BizTalk
- Did a demo where he used XQuery to pull data out of message. Cool!
I'm really impressed with Roger's skill as a speaker and the demo. Folks, you
really should be at least looking at this technology.
I'm going to get fat on hat calories pretty soon. Michael Rys points out some over generalizations I made here with this.
No worries, Michael, about how I take your comments. I'd prefer to have to clear and right.
Just cleaning up my memory stick. Click for larger image.
Barry, Eli and Marcie
The DataGridGirl and Enjoy Every Sandwich.
Doh! Yet again, I missed the donuts.
Gert Drapers is doing this session. Should be fun
- Adding tons and features and making continued investments in this
technology.
- Standard list of new features
- Ranking functions
- Talked about Rank, Dense_Rank and RowCount
- Ranking helpful in data analysis
- Uses SQL Standard OVER syntax
- Talked about PIVOT and UNPIVOT
- Talked about the changes to TOP
- Common Table Expressions
- Sort of like an enumerator
- with <name>(cols...) as name (sub-query)
- Example: select empid,empname,mgrid from employees where id='12345'
union all select e.empid, e.empname, e,mgrid from employees e where ...
doh, missed the rest.
- Use union all to merge
- Recursion stops when subquery returns nothing.
- Filtering should be done on outer query
- Expect some performance gains from doing this since QP will have a
better clue.
- Indexing changes
- ALTER INDEX syntax
- Talked about ALLOW_ROW_LOCKS, ALLOW_PAGE_LOCKS, MAXDOP and ONLINE.
- New functions fn_indexinfo and fn_virtualindexstats
- Indexed View Changes
- Compilation time improved
- Scalar aggregates and Scalar UDFs
- Improved the query-to-undexed-view matching
- Computed columns are intelligently used
- Improved intelligence of ranges
- A bit of conditional equivalence usage
- XML showplan was done for efficiency reasons
- Discussion of table variables now supporting INSERT...EXECUTE
- Snapshot isolation (think Oracle)
- Increased access (readers don't block writers, writers don't
readers)
- Mandatory consistency checker
- At the database level
- Trade of is CPU and I/O for a consistent view
- Did a demo of setting this up.
- Clash resolution is at the cell, not row, level.
- Added Data Types: XML, n/varchar(max) and varbinary(max)
- Confirmed Date, Time and UTCDateTime have removed
- Talked about XML Data Type
- Talked about the new MAX types with a 2gb limit. No need to text
pointers, Can now be used like any other data-type (essentially.) Chunking
is still supported.
- Talked about updating BULKINSERT with OPENROWSET
- DRI changes
- Adding SET DEFAULT and SET NULL via DML
- Talked DML without output
- Access to inserted and deleted
- update orders set status='processed' output deleted.*,inserted.*
where status='uncprocessed'
- Yields better concurrency
- Talked about DDL triggers
- Scoped at the server and database level
- Data in eventdata() function
- Useful for rule inforcement
- Protect from drops
- Check-in, check-out
- Source versioning
- Log management activity
- Talked about statement recompilation
- Discussion of TRY...CATCH
- B1 was essentially limited to a transaction abort
- B2 will catch @@error, simplies the Try Catch Syntax and cleaner
error raising
- Can be nested
- Details in EventData, error_number(), etc
- BEGIN TRY/END TRY, BEGIN CATCH/END CATCH
Fairly good session, I was pleased that Gert wasn't afraid to talk about the
dropped features and I felt like he gave us the straight dop about the product.
I had to do a double take during Michael Rys's presentation on the XML Data Type in Yukon. Suppose you have a XML-typed column and you want to perform some content or free-text (full text) searching on it. The classic example of this might be loading the XML version of a Word Documents representing resumes into an XML Typed column, then wanting to do various types of searches on the resumes for patterns of words. More likely than not, XPath and XQuery won't be efficient means to that end, but full-text searching would be. However, the indexing process ignores attributes values.
At the heart of the issue is the document-centric XML vs Data-Centric XML debate when it comes to the use of elements and attributes. I asked Michael about this after the session. His point, if I'm recalling it correctly, is that in document-centric XML, attributes aren't normally of primary interest, since they used to either indicate or modify meta data. It is unlikely that anybody really would be interested in doing a full-text search on that kind of data. But that's not always the case. Consider the following schema, then suppose you want to search on the type attribute. This could happen if the type of types is not constrained in a meaningful way.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:element name="address">
<xs:complexType>
<xs:sequence>
<xs:element ref="street"/>
<xs:element ref="routing"/>
<xs:element ref="local"/>
<xs:element ref="region"/>
<xs:element ref="postalCode"/>
</xs:sequence>
<xs:attribute name="type" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="local" type="xs:string"/>
<xs:element name="postalCode" type="xs:int"/>
<xs:element name="region" type="xs:string"/>
<xs:element name="routing" type="xs:string"/>
<xs:element name="street" type="xs:string"/>
</xs:schema>
Now, I agree that you could make the type attribute an child element of the address element, but suppose that's not an option since adhering to the schema is paramount here. The next best choice? If you really need to do this kind of search, consider extracting the attribute value of interest into a simple scalar string value (use an appropriately sized nvarchar, for example) and do you searching on that. While denormalization can be considered a sin, here it may make some sense.
This isn't going to be as functional as FTS where there is a metric known as "rank" that computes the relative "goodness of fit" of an item to a search phrase. When you denormalize the attribute like this, the underlying factors that are considered when computing this rank are lost, so the ranking computation loses much of value. I'm not sure if there is a good workaround for this affect.
Yes, this is a bit of contrived example: You probably would constrain the allowed values for the address type so you could preform normal T-SQL type filtering rather than FTS in the first place. Ah, if only all such things could be discovered and addressed in design...
Mouthful of a title. About 15 bodies in the room.
- SMO is the replacement for DMO. DMO is depreciated. SMO is managed code.
Most DMO applications should port smoothly.
- SMO will be feature compatible with DMO. Not exactly 1-to-1, but
anything you did with DMO, you should be able to do with SMO.
- SMO will be an MSI if you need to redist it. Must have SQL native client
and framework 2.x
- Design goals
- Fully cover Yukon's features
- Improve scalability and performance
- Simple but rich object model
- Friendly towards scripted use
- What's new
- All server features covered
- Cached object means that changes are committed immediately
- Capture of T-SQL
- Real-Time server ends
- WMI Wrappers
- Why used: its a lowered barrier to entry, integrates with applications,
isolation from metadata and DDL changes.
- Team had a goal of avoiding T-SQL
- Demo of building an application
- Cool little app to integrate tables. Kind of blows me away how
little code that it really takes to make this work out.
- There are a few tricks that will help you tweak out the performance.
The goal remains, however, get just the data you need.
- Interesting demo of doing index management.
- With DMO, the root object is the server, not the application. This leads
to a releasable state.
- SMO fully supports scripting and the SMO Scripter is a stand-alone
object.
- 2-way dependency filtering
- Dependency pruning
- Progress events
- Covered exceptions. They are chained, but they usually thrown as close
as possible to the event that raised them (rather than bubbling up.)
Jumped out of the session early to fetch a Latte. Informative session, I
thought.