Today is the general availability release date for the newest version of SQL Server, aptly named SQL Server 2014. I’m excited about many of the new features being rolled out today, but the ones that will impact data architects, modelers and database designers are the new datatypes that will be introduced. But first, for those of you who have their heads stuck in the deep piping and spit-managing of databases, some background about datatypes:
A datatype is a categorization of data items, based on the range and types of data that it can contain and a set of actions that can be validly taken against that data.
As such, applying a datatype to a column in a database makes it work as another type of constraint. A tinyint column can’t hold my Starbucks name (Kitty) because it constrains the values to integers and only a subset of all integers, for example.
The number and type of datatypes (yes, I’m being meta there) varies depending on the strength and quality of the tequila the DBMS product management teams were drinking at their last
Vegas Blow Out team building retreat, as called for in the ISO Standards for databases, AKA
ISO/IEC JTC 1/SC 32 - Data management and interchange.
One of the things that developers and DBAs will tell you is that choosing the right datatype is important for performance reasons. And by that, they mean the smallest datatype you can fit most of the data in. And maybe a bit smaller. Soooo much bad info out there, I know. When Knowledge Conquers Fear, we can love our data. Thank the Cosmos you have me here to help you out.
What’s new in SQL Server 2014: A New Datatype
This new datatype is exciting for me as a data & space enthusiast. The new feature finally allows modern database designers to properly specify the constraints for tracking time and location data in the same column. Yes, this means that your developers and DBAs no longer have to use comma-delimited values in their relational database designs when they need to track how much time and personal space they need to get up to speed on professional database design. And it’s big enough to store that many man-hours. Yeah. I said that.
BTW, it seems that Stack Overflow is *the* place to find info on how to implement comma-delimited values in database columns. Kids, don’t get your database design knowledge from random forums on the Internet.
Anyway, back to the news!
The new feature makes so much sense with Microsoft’s push to the Cloud, it’s embracing of NoSQL technologies and all. It’s AWESOME.
Defines a time and location in a universe.
SQL Server 2014
spacetime [(fractional seconds precision)], (universe, 5DGeometry)
CREATE TABLE Table1 ( Column1 spacetime (1000, 2014.12.0.2000.8
-∞ to +∞ and beyond
[you’ll need a 5D monitor to view this range.]
Timezone offset range
Thank Venus, no, nope, never. We are scientists here. Use Multiuniversal Universal Time Coordinates (UTMC).
Daylight saving aware
Oh, for Carl’s sake. Do you really think something like spacetime needs to be sullied by DST?
If you have to ask, you don’t ever need to use this datatype. Seriously.
+/- 10 Planks. Depending on how far your server is from the Sun. Earth’s Sun, that is.
Microsoft Azure DB Support
|Yes, of course. But only in Premium plans and higher.|
Special Considerations and Gotchas
Some gotchas with this new datatype:
- Due to the highly multi-dimensional, multiuniversal nature of this datatype, there isn’t any backwards compatibility. Unless, of course, you can fold spacetime and go back and change earlier versions of SQL Server. But if you could do that, you wouldn’t be reading my blog, would you?
- Just like the confusion over timestamps, you can’t really treat this like a date or time datatype. It’s special. And spatial.
- This means you can’t convert it to date, time, datetime, timestamp or spatial datatypes, either.
- The 5D geometry thing is way too complex to explain in a single blog post. But for those of you that managed to stick it out through some college level math, it involves parsecs (the correct usage of the term) and the double declining balance method of space depreciation. In this first rollout of spacetime, the geometry completely ignores most OctoDeca Bands. Except for Miller tracks.
- You can’t use normal date and geometrical math on data in the columns. You can bend or fold the values, but since space has no center, and time has no beginning or end, spacetime has no beginning or end. It is infinite. So the usually infinity rules apply.
- This datatype is only available via O365, but that makes sense since as announced today, SQL Server 2014 is also only available via O365 subscriptions.
- This datatype is only available at O365 plans at U3 and higher. Wait, I don’t think I should have said anything about the new Universe O365 plans. Forget I said anything. That’s probably not going to be a rule in our universe. Seriously. No NDA broken. I think.
Some of this post may have been inspired by some bad veggie April Fish (poisson d’avril) I had last night. If you want to get some real information about the new features of SQL Server 2014, you probably shouldn’t read random blogs on the internet on launch day. Especially when it’s 1 April.
Did you catch all the special references in this post? Let me know.
At the upcoming Enterprise Data World 2014, I’ll be doing a half-day presentation on Driving Development Projects with Enterprise Data Models.
Here are a few teases for what we will be talking about:
Join this session to see how data fits in real-world enterprise development projects. We’ll answer such questions as:
- "Who does what?"
- "Why are we doing this?"
- "Will it slow things down?”
- “Will it work with agile development?”
- "Will I have to actually talk to a data architect?"
- “What about the Cloud?”
- "What are the biggest mistakes teams make?"
- "Will I still have a job?"
The session will feature demos of common data modeling-to-database processes, including reverse engineering, forward engineering, generating DDL, alter scripts, and more. You will leave with 10 tips for making model-driven database development successful in your organization’s culture and environment.
Me: Hi, Neil, I’m Karen
Neil: Hi, Karen….
Slides from my frequent DAMA / Enterprise Data World presentation on Data Modeling mistakes. You can click on the stopwatch in the player to auto-advance the slides.
There’s no sound; these are just the slides. If you’d like attend a presentation on this topic, ask your local user group (DAMA, ERwin, PASS, etc.) to invite me.
Sure, data modeling is taught in many training classes as a linear process for building software. It usually goes something like this:
- Build a Conceptual Data Model.
- Review that with users
- Build a Logical Data Model
- Review that with users
- Build a Physical Data Model
- Give it to the DBA
- GOTO step one on another project.
And most team members think it looks like this:
Training classes work this way because it’s a good way to learn notations, tools and methods. But that’s not how data modeling works when the professionals do it on a real project.
Data modeling is an iterative effort. Those integrations can be sprints (typical for my projects) or have longer intervals. Sometimes the iterations exist just between efforts to complete the data models, prior to generating a database. But it’s highly iterative, just like the software development part of the project.
In reality, data modeling looks more like this:
This is Data Model-Driven Development. The high-level steps work like:
- Discuss requirements.
- Develop data models (all of them, some of them, one of them).
- Generate Databases, XML schemas, file structures, whatever you might want to physically build. Or nothing physical, if that’s not what the team is ready for.
These, again, are small intervals, not the waterfall steps of an entire project. In fact, I might do this several times even in the same sprint. Not all modeling efforts lead to databases or physical implementations. That’s okay. We still follow an iterative approach. And while the steps here look like the same waterfall list, they aren’t the same.
- There isn’t really a first step. For instance, I could start with an in-production database and move around the circle from there.
- We could start with existing data models. In fact, that’s the ideal starting point in a well-managed data model-driven development shop.
- The data models add value because they are kept in sync with what’s happening elsewhere – as a natural part of the process, not as a separate deliverable.
- The modeling doesn’t stop. We don’t do a logical model, then derive a physical model, throwing away the logical model.
- Data modelers are involved in the the project throughout its lifecycle, not just some arbitrary phase.
- Modeling responsibilities may be shared among more roles. In a strong data model-driven process, it is easier for DBAs and BAs to be hands-on with the data models. Sometimes even users. Really.
By the way, this iterative modeling approach isn’t unique to data models. All the models we might work on for a project should follow this project. Class diagrams, sequence diagrams, use cases, flow charts, etc. should all follow this process to deliver the value that has been invested in them. That’s what Agile means in “the right amount of [modeling] documentation”. Data model driven development means that models are “alive”.
If you are a modeler and re-enforcing the wrong perceptions of needing a waterfall-like approach to data modeling, you are doing it wrong. You might be causing more pain for yourself than anyone else on your project.
Data Models aren’t just documentation checklist items. They model the reality of the living, breathing systems at all points in its life. They deliver value because they are accurate, not because they are “done”.
Slides from my frequent DAMA and Enterprise Data World presentation on data management career success.
Subscribe via E-mail
- Ray on 1 Second Guide to Not Being a Jerk on GoToMeeting
- Luke Jian on Scarborough Merry Maids…Are Terrible at Making Mistakes. Are You, Too?
- M Brinkley on SQL Server 2014: New Datatype
- Roger Wolter on SQL Server 2014: New Datatype
- Ayman El-Ghazali on SQL Server 2014: New Datatype
- April 2014
- March 2014
- February 2014
- January 2014
- December 2013
- November 2013
- October 2013
- September 2013
- August 2013
- July 2013
- June 2013
- May 2013
- April 2013
- March 2013
- February 2013
- January 2013
- December 2012
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- September 2010
- August 2010
- July 2010