Sybase loves AdventureWorks2008?

reedme — Thu, 22 Jan 2009 19:24:38 GMT

A SQL Ranger friend of mine in the UK gave me the heads up to this yesterday. (Thanks, Ben!!) Apparently, back in December 2008, Sybase ported some of our samples to SQL Anywhere. Needless to say, I’ve got mixed feelings about Sybase porting AdventureWorks to their platform. Sort of like a cherry-cheese Danish: it’s a pastry and pastries are supposed to taste good, right? But cherries and cheese? Ick. (I’m on a severely calorically restricted diet; sorry for the digression.)

As SQL Server 2008 and SQL Anywhere 11 are two very different database solutions, the ‘AdventureWorks2008’ database will appear slightly different, and offer a few functional differences. These incongruities are the result of different feature sets, which are intrinsic to each database’s design. AdventureWorks2008 Sample Database for SQL Anywhere Download: Mobile Enterprise, Database Management iAnywhere - Sybase Inc

We license AdventureWorks under the Ms-PL, so anybody’s welcome to do whatever they want with our code. It’s out there for learning purposes. Sybase seems to have learned that SQL Anywhere 11 doesn’t do a lot of the really cool things that SQL Server 2008 does! They only ported the OLTP database – I wonder why they ignored DW and LT??

The Sybase port of AdventureWorks2008 drops the following features:

They dropped all the spatial columns because SQL Anywhere doesn’t have a geography type.
They dropped Try/Catch error handling in all stored procedures, since they can’t do that.
They dropped DDL triggers, because SQL Anywhere doesn’t have them.
They dropped all stored procedures with recursive queries, because they don’t support them.
They dropped all Full Text indexes and queries, since SQL Anywhere doesn’t do that, either, I guess.
They dropped or modified all tables with HierarchyID columns, because they don’t have that data type.
They dropped all the tables with XML data, or omitted the XML columns, because they don’t support the same XML query lingo and have no XML index support.
They dropped all the indexed views, because SQL Anywhere doesn’t do that,either.
They dropped all the views that use PIVOT, because (guess what?) they don’t have that keyword.
They had to modify a bunch of stored procedures because they don’t support EXECUTE AS CALLER. (Did I mention that they had to drop all the Try/Catch support, too?)
They had to emasculate most of the trigger functionality (not counting the DDL triggers they had to drop outright), because they don’t support those features. Such as dropping Try/Catch support to throw exceptions instead of logging and always updating certain columns (even when not appropriate for the business rules):

HumanResources.dEmployee
Person.iuPerson
Production.iWorker
Production.uWorkOrder
Purchasing.iPurchaseOrderDetail
Purchasing.uPurchaseOrderHeader
Purchasing.uPurchaseOrderDetail
Purchasing.uPurchaseOrderHeader
Purchasing.dVendor
Sales.iduSalesOrderDetail
Sales.uSalesOrderHeader

They had to truncate all the binary image columns to 32,767 bytes (which will break all the ones bigger than that) because SQL Anywhere doesn’t have a large binary type apparently. Whoops!

Anyway, I don’t have a SQL Anywhere installation to try it out on, but that list from their own website reads (to me) like a list of reasons to use SQL Server 2008 instead. It looks like they ported our .NET samples for AdventureWorks2008, too, so I have to wonder if they’re equally limited as the AdventureWorks2008 port?

I do hope that SQL Anywhere customers do get some benefit out of using the port of our sample OLTP database (or switch to SQL Server 2008 where they can get the full functionality of AdventureWorks2008). I’d also like to invite Oracle and DB2 to port AdventureWorks2008 to their platforms so that the world can see how much of our feature set they don’t support, either. Heh.

How reliable is your data source?

reedme — Thu, 11 Dec 2008 02:13:29 GMT

It seems like aeons ago (not even a decade yet) when I was @ a little start-up that was assimilating real estate data to further our digital business model and making sales to web-savvy home buyers at a discount. So many funny stories, so little time...

The data from every MLS system we assimilated had its own little quirks. It seems that REALTOR®s aren’t the best data entry clerks (who would’ve imagined that there are 71 different ways to spell Chicago?), but maybe it’s not just REALTOR®s. It could be that humans aren’t very good at reliable data entry.

New York City takes this to a whole new level of insanity, though. Allowing for a trivial paper crime to “steal” an entire skyscraper??

The massive ripoff [the theft of the Empire State Building] illustrates a gaping loophole in the city's system for recording deeds, mortgages and other transactions. It took 90 minutes for Daily News to 'steal' the Empire State Building (nydailynews.com)

Since everybody’s hyper-aware these days of the fragility of our mortgage system, how is it that the largest city in the county allows this to continue in the 21st century?

If you’re doing business based on somebody else’s data... how certain are you that you’re making the right decisions? I’m not going to call “business intelligence” an oxymoron like many people do “military intelligence”, but they do sound the same... don’t they? What risk mitigation are you doing to prevent executive decisions from being made @ your compnay based on the equivalent of a Ouija board (data from somebody else’s system)?

Maybe Skynet has a point about humans...? Er, wait a sec-!

Reed Me : data quality

Sybase loves AdventureWorks2008?

How reliable is your data source?