Stuart Ainsworth

#SQLSat35: Dallas 2010 notes

I realize that it’s been an entire week since SQLSaturday 35 in Dallas and that’s an eternity in the blogosphere, but I’ve been recently reminded of a very painful lesson: you pay for taking days off.  Two days out of the office to go to Dallas cost me much more than two days worth of work; I’m not sure what temporal and spatial laws are in effect that cause this, but it’s damned annoying.  It’s not making me look forward to next week, when I’m taking the entire week off; I should be behind for the rest of the month.

Anyway, the trip to Dallas was especially great for me; I grew up in Northeast Louisiana, and many of my friends moved to the Dallas area after college.  Unfortunately, I was only able to catch up with two of them (Evan R. and Brad W.); they graciously allowed me to use their couches, saving me a lot of coin for what was essentially an unpaid employee training expense.  It was great catching up with them, and I hope to be back that way in the near future.

This particular SQLSaturday was also very cool because it’s the first one that I attended simply as an attendee and NOT as a speaker; this was eye-opening for me, because it gave me a chance to experience some things as an outsider (although I did crash the speaker’s dinner on Friday night), and that gave me a chance to reflect on what it’s like to not know all of the details about an event, and what can be done to make sure people know what’s going on when, where, and how.  I’ll get to that in a second, but let me throw some thoughts out there.

What Worked Well…

I don’t think anyone can say enough about the team of volunteers from the North Texas SQL Server User Group; these guys simply ROCK, and they pulled without a hitch.  I especially liked the fact that they spread out the work effort over several volunteers, and that every member of the team took their responsibility seriously.   In my mind, however, there were a couple of amazing contributions at this particular event that often get overlooked, so I want to give a quick acknowledgement to them:

  1. Having a designated photographer was a great idea.  Everywhere I looked, there was a volunteer taking snaps.  I’m not sure where those pictures will be posted, but we’ve had volunteers in the past take some great photos, but never really treated them as a full-time member of the team. I think having someone designated to capture the memory of the event is a great idea, particularly if it can be folded into networking opportunities later.
  2. The food and food distribution was amazing; whoever picked the caterers did a great job, and the way it was laid out was simply wonderful.  Although I loved the ice cream at the end of the day, the sugar rush (and subsequent crash) was a bit tough for me personally.  Great idea, but unexpected side effects; I slept through most of the last session 🙂
  3. Finally, Ryan Adams was the sponsor coordinator, and I watched him work those tables several times throughout the day.  That was a nice touch, and I hope the sponsors appreciated having someone who was available to them all the time to handle any issues that they may have had come up.

Others have noted how great the facility was; I couldn’t agree more.  I’m hoping that we can find a similar venue for our next SQLSaturday in Atlanta.  Registration worked great; I think having an early morning raffle incentive helped keep the distribution of the attendees relatively constant, and they had several lines available for people to check in.   I did feel a bit of “what happens now” after I made it through the line, but it was easy to spot where everyone was hanging out.

One thing that I really liked was the use of a claim ticket for filling out speaker evals; we had done something similar for the last Atlanta event, but the Dallas crew did it a little different.  Each attendee got a single ticket at the beginning of the day, and they used that same number throughout the day to fill out speaker evals.  Unlike us, however, they chose to do all of the drawings at the end of the day.

Finally, the event guide was amazing; it was very thorough and complete, and looked very professional.  All in all, I think the event was a wonderful day, and I hope people really appreciated how well things were handled.

What Didn’t Work So Well…

There were a couple of minor issues, however, and I mention them only so that other SQLSaturday coordinators can plan from them.  The brochure was wonderful, but the central schedule was organized around tracks, not times, which meant that if you were hopping tracks, you had to keep scanning in order to find the time something was occurring in order to see what classes were available.  This was a departure from the traditional scheduling format, and I just think it didn’t work as well as the planners hoped.  The planning team did have a great web tool for picking a schedule, and I noticed that many people were walking around with paper copies of those; those schedules were the traditional arrangement by time.

Second, and this was completely minor, I felt lost at the beginning of the day.  Again, this was the first event I’ve been to in a long time where I was simply an attendee, and it was a little overwhelming to go from the registration desk and walk into a mass of people milling about.  I’m not sure what can be done about that, but I’m wondering if introducing an usher would help make that transition slightly less disconcerting.

Third, the sponsors were responsible for providing their own tickets; this was both good and bad, so I need to follow up with sponsors about how they felt about it.  Waiting on people to fill out forms did create a traffic jam, but it completely took away some of the set-up responsibilities from the organizers.  The sponsors may also have benefitted from having people hanging out.

Finally (and this happens at every SQLSaturday I’ve been to), I don’t think enough mention was made of the fact that there is a thriving SQL Server community that meets every month behind every SQLSaturday.  We get so caught up on the day, that we forget to give enough shout-outs to the local or national PASS communities.  Tim Mitchell tried to do that at the end of the day, but it was done after the raffles were over and people were packing up to leave. 

These, of course, are minor quibbles; overall, it was a great day of training.  The classes I went to (for the most part) were excellent, and I felt like I came back with some new ideas to try out.

Plans For Future Events…

So here’s my final take-away, and what I plan to do at the next Atlanta SQLSaturday:

  1. Punch up the mention of the local chapter and PASS a LOT.  Focus on getting people connected to those organizations.
  2. Reward people for making connections; find some variant of Twitter Bingo to help people make local connections.
  3. I loved the claim check idea with a single number for the whole day; I think we’re going to steal it, but continue to do raffles in-session and save the big prizes for the end of the day.
  4. Contact the sponsors and ask them how they want to handle raffle tickets in the future.

Other Writeups….

A lot of other people have already written about their experiences at SQLSaturday 35′; in case you missed them, here’s some of the ones I read:

SQLAJ – What I gained from volunteering at SQLSat35

MidnightDBA (Jen) We Made This, Part 1 of 2 (Thoughts on SQL Saturday 35)

Made2Mentor: My SQL Saturday Experience

Ryan Adams: SQL Saturday Weekend Palooza

Bill Fellows: SQL Saturday 35 experience #sqlsat35

Wes Brown: SQL Saturday #35 Notes and Observations

#sqlsat35 looking ahead to the weekend

This weekend I’ll be traveling to the DFW metropolitan area to attend SQLSaturday #35; I’m very excited about it.  I didn’t know if I’d be able to attend this weekend (had to trade kid time with the ex-wife), so I missed the call for speakers.  I am looking forward to actually attending sessions and bumping into some friends.   If you’re there, look me up; I’ll be wearing my SQLSaturday #41 t-shirt (see this link for a sample).

I’ll be packing a couple of presentations (just in case they have an opening): the Social DBA and my latest discussion on XML in SQL Server 2008.  I was planning on submitting both of them to PASS Summit this year, but I feel a little guilty about the Social DBA one given that I’ve completely slacked off over the last few months.  I keep thinking I’m going to get back on the wagon, but life has been flying by much too fast these days.

Speaking of friends, Dallas is kind of like an old home to me; I grew up in Louisiana, and many of my high school and college buddies wound up in the big D after graduation.  I’m looking forward to crashing on a few couches, having a few beers, and hearing what happened over the last 20 years or so.

Speaking today: PASS AppDev Virtual Chapter

I know it’s short notice, but to be honest, I totally forgot about this until a couple of weeks ago.  I’ll be presenting today at noon eastern on a LiveMeeting for the Application Developers Virtual Chapter of PASS.  Deets below:

“You Got XML In My Database? What’s Up With That?”
May 11th 12:00 PM EDT (GMT -4)
Add to Calendar
Presenter: Stuart Ainsworth

A brief presentation exploring the marriage of XML and relational databases, including when it works and when it doesn’t. Coverage will include various use case scenarios, and some tips on how to improve performance using design techniques.

Stuart Ainsworth

Stuart R Ainsworth, MA, MEd is a Database Architect working in the realm of Financial Information Security; over the last 15 years, he’s worked as a Research Analyst, a report writer, a DBA, a programmer, and a public speaking professor. He’s one of the chapter leaders for AtlantaMDF, the Atlanta chapter of PASS. A master of air guitar, he has yet to understand the point of Rock Band (“You push buttons? What’s that all about?”).

How do I view the presentation?
Attendee URL:  Live Meeting link

SQLSaturday #41 Wrap-up: Lessons learned from Atlanta, April 24, 2010

So this wrap-up took a little longer for me to write than I had hoped; work had piled up a bit post-con, and finals were going on in the class I teach part-time at Gainesville State College.  Nonetheless, I’ve been thinking a lot about what happened at the third SQLSaturday for AtlantaMDF, and hopefully this list will help some of the other groups prepping for their event.  Before I get started however, you may want to review my life lessons from SQLSaturday 13 and 25.  Go ahead; I’ll wait.

Ready?  Before I go too much further, I should note that there have already been a lot of write-ups about the event from the speakers; I’ll try to build a list of them below my notes, but I will be borrowing liberally from some of them (particularly Jen McCown’s post at http://midnightdba.itbookworm.com/midnightdba/blog/post/A-MidnightDBA-in-Atlanta-(SQL-Saturday-41).aspx).  I’ll try to give credit where credit is due, but in case I overlook someone’s contribution, please feel free to point it out.

Pre-con preparation

Here’s a list of stuff that I could have managed a little better BEFORE the conference began.  Again, I don’t think we did anything bad; I just want to improve it for next year.

Committee Work.

This particular SQLSaturday was a new challenge for me; the previous two SQLSaturdays I had done most of the leg work before the conference by myself, and only really accepted volunteers to help on the actual day of the event.  That had pluses and minuses; the pluses were that I became very aware of some of the larger issues associated with putting the event on.  The minuses were that I was a raving lunatic for several weeks, including the day of the event.

This year, I tried to put together a committee, and there were some different challenges with that; there was a lot of energy among the members of the group, and that led us to do some things that I wouldn’t have normally tried (good thing), but it also meant that we spent a lot of time debating how to do things (not a bad thing; just something to account for in the future).  The biggest plus for me was delegation; the week of the event, I actually had a very small list of things to do, and that was wonderful.  Other people on the team really stepped up and took care of a lot of issues for me.

I definitely think working with a committee is much better than attempting to do it solo, but I would still recommend that you have a definite committee leader (someone with veto power).  If I were to do it all over again, I’d be much more strict about working with a punch list (more on that in a minute); we had a lot of ideas floating around, and unfortunately, most of them were in my own head.

Start legwork earlier.

I’ll admit it; I procrastinated on this event.  My divorce wasn’t final until March 8, and I basically didn’t do enough work on this event before that to make it a smooth project.  I think it came off well, but we were playing catch-up for the last month.  As the project manager, this was solely my fault; I even had several members on the team to act as designated “butt-kickers” for me.  I don’t think it would have changed the outcome much, but it would have been less stressful.

Building a better event guide.

As most of you know, the event guide is the key to a good SQLSaturday.  I didn’t deviate much from my previous event guide formulas (schedule on the front page, summary of speakers bios and sessions on the following pages, sponsor logo throughout).  In hindsight, there are some things I should have done.

  • Jen recommended that we have a map of the rooms; we did.  It was on the last page of the guide.  I should have made it MUCH more obvious because we were dealing with several tracks.
  • We (I) decided not to have a keynote session; we were expecting more people than we had room to hold in our largest conference space.  I should have taken the time to write out what to expect and where to go.  I answered a lot of basic questions over and over again on the day of the event (what do we do with raffle tickets, where are the extra restrooms, etc.).
  • I’m not sure if the speaker bio is as relevant to the session attendance as we think; it may be better to have either a separate speaker book OR simply recommend that speakers do their own bios as part of the session.  We could have trimmed the book down quite a bit.  

How many people are we talking about?

I completely underestimated the response from attendees, speakers, and sponsors.  SQLSaturday has been around long enough that I think everyone is on board these days, and we definitely did not lack anything in terms of attendee registrations, speakers, and sponsors.  Our biggest challenge was space; I chose to reuse the Microsoft facility in Alpharetta because a) it’s nice, and relatively close to a tech hub in Atlanta, and b) it was free (Microsoft was a Gold sponsor).  Again, not a bad decision, but a decision that had consequences; we could only have 250 attendees in the rooms AND we needed to enforce room counts.

Before the event began, we had 250 people on the registration list and almost 100 people on the waiting list at one point.  We did this with minimal advertisement, and I think we could have easily hit 500 registered people if we had done more advertisement.  What really surprised me was the number of sponsors that responded as well as the number of speakers that submitted.  I made the not-so-smart decision to accept most submissions from speakers (I had a few complain about that; suck it up, Kendal); this meant that many submitters were presenting multiple times, and I was trying to evenly distribute 250 people across 7 tracks.  To keep the session count high, I decided to add an extra hour to the day (start early, end late).   7 sessions is too many, so next year I’m going to have say NO to more sessions by speakers.  However, I still want to encourage new speakers to apply as well as the more established circuit riders; I love Robert Cain and Kevin G. Boles (and they draw crowds), but I still want to hear from Audrey Hammonds and Julie Smith.

Sponsor participation was amazing (we had 14 sponsors; 6 of them a type of Gold), but I have bad news for my sponsors for next year; if we’re going to have to pay for space, our price levels are going to have to go up.  We’ll make it reasonable, but I may have to introduce a Platinum level for larger sponsors.  The good news is that while the overall cost will go up, we’ll be able to deliver a larger list of attendees to them and a broader reach.  In keeping with the comment above about getting started sooner, I plan to talk to a few of my regular sponsors and get their feeling on what was reasonable and what is fair.

The T-shirt.

I had chosen in the past to NOT do an event T-shirt, and Aaron Nelson (one of our committee members) talked me into doing one this time.  My past arguments about the shirt included a) I didn’t want to deal with sizes, and b) most people would wear the shirt for 1 time and then it would become a gardening or paint shirt.  We couldn’t do anything about sizes, but Aaron and I talked about a couple of different options for the shirt so that it wouldn’t be a typical wear-it-once kind of a thing.  We decided to come up with a geek-friendly saying on the front, and a simple advertisement for the event and the local user group (AtlantaMDF).  Here’s one of our happy raffle winners at the end of the day wearing the shirt!

Did it work?  Dunno; by the end of the day, all of the extra shirts were gone, and that’s unusual for an event of this type.  I had a lot of people asking me if they could grab one for a co-worker, or a youth group, and even a math class.  For all I know, there’s a family of four out in Dunwoody somewhere doing yardwork in the shirt we designed, but I hope that a least a few of my fellow data geeks will wear them in public or at work and advertise the next SQLSaturday (and AtlantaMDF and PASS). 

 

The Raffle Tickets for In-Session Drawing.

To me, this was one of the best ideas we had for SQLSaturday, and I am definitely going to keep doing it in the future.  We decided this year that we were going to do in-session drawings for swag in order to keep the final session as short as possible (all we had to do at the end of the day was draw tickets from our big sponsors).   After a lot of debate on how to do this, we finally decided that we would do the following:

  1. Hand each session attendee a raffle ticket and a speaker evaluation form.  The attendee would fill out the speaker eval form, and use the ticket number instead of a name on the form.
  2. The speakers would draw for prizes from the speaker eval forms, calling out the ticket number for a winner.

The benefits?  Fast drawings for prizes, session feedback was confidential, and the speakers got immediate feedback (no tallying necessary).   There were some challenges; attendees got confused by the word name on the speaker form, and were unsure what to write.  Next year?  Do it more like a claim check, with the number already assigned to the individual eval form.  I may have to spend a little money on perforated paper, but it should make it go easier.

Day Of The Event

Obviously, there were things we could have done on the day of the event better; we get a little better each year, but there’s always stuff to improve.

Registration

Our registration staff was AMAZING; unfortunately, there wasn’t enough of them.  We should have had more than two lines, particularly since we were expecting 250 people + wait list to show up before 8:30 AM.    A good formula is probably 100 people per line, with at least 2 hours of registration time.  The good news is that our head registrant (Lorra Newton) is thinking about writing an app to help speed up registration next time; we’ll discuss next time.

Sponsor Pit

We had to stuff sponsors into a relatively small area this year in order to make sure they had power; I know that it may have been an inconvenience, but I think it actually helped facilitate conversations.  The small space made the sponsor pit look busy, and busy places draw a crowd.

Better Training For Volunteers

Volunteer participation this year was amazing, and we did a better job than last year of pre-organizing the volunteers.  I still think we could do better, and we may need to see about making pre-con meetings mandatory for volunteers in exchange for greater rewards (a custom t-shirt, free lunch, something).  We were training people on the morning of the event, and there were a few mix-ups (like the aforementioned speaker eval/raffle claim check).

Lunch Tickets

Like the last two events, we charged a lunch fee in order to keep attendance high; when people pay for an event, they tend to show up, even if the event has only a nominal fee.  Unfortunately, we don’t do enough to distinguish between the fee for the event (FREE) and the fee for lunch.  I think next year, we’ll need to do lunch claim tickets to allow people to not pay for lunch and still come (bring their own or pay at the door).   Of course,  we’ve used non-payment of lunch fees in the past to help clean up the list before the event, and we’re not doing that anymore; we do, however, need to find ways of verifying that people will come, particularly if we have space limitations.

Session Scheduling

I need to be more sensitive to back-to-back scheduling for speakers; if I’m going to have them go back-to-back, then I need to put them in the same room.  Speaker schedules are always a bear; no matter what you do, you’re never going to get it perfect.  I think having a tighter schedule will help, but I still need to get better.  We did do a pre-conference survey to determine space requirements (large classes vs small classes), and that helped immensely, but I forgot to check for a balance of advanced, beginner, and intermediate classes during each hour of the day (the last hour of the day I had 1 advanced session, and the rest were all beginners; we had a bit of crowding at that point).

 

Post Con Activities

No doubt about it, I need to set realistic goals for wrapping up the event.  I still haven’t sent out sponsor emails, and I’m just now finishing the writeup.  I should have delegated some of these activities to volunteers, but simply didn’t.  That’s definitely on the list for next year.

There’s also more work to do, but I’ll save it for another post; I need to compile a list of blogs and photos from the event.  Hopefully that will come out in the next few days.

SQLSaturday 41 Status Update

I know many people have been worried about me because of the recent personal issues that I’ve been dealing with, but things have finally started to stabilize.  I know I’ve promised that before, so no promises to return to blogging or getting more involved in the community, but I’m starting to climb out of the pit (and hey, I have light bulbs)!

Anyway, despite me, SQLSaturday 41 on April 24, 2010 is plugging along, thanks to a group of dedicated volunteers that have really pushed me to keep this on track.  Thankfully, I’ve been able to give them the information they need, and they’re quite capable of making this happen.  We’re a little more than a month out, and we’re almost full with our speaker’s list, and are sitting at nearly 60% registration.  Seats ARE filling up, so if you haven’t registered, now’s the time to do so.

Here’s a short list of topics so far (in no particular order):

A Lap Around SQL Server 2008 Master Data Services
Whitney Weaver
Beginner

Advanced Parameters in SQL Server Reporting Servic
Mike Davis
Intermediate

Can you control your reports?
Ryan Duclos
Intermediate

Common Table Expressions
Ryan Duclos
Beginner

Data Warehouse Assessments – What,Why, and How
Noah Subrin
Beginner

Database Design Fundamentals
Louis Davidson
Intermediate

Database Design Patterns
Louis Davidson
Intermediate

De-mystifying Execution Plan Analysis
Dave Turpin
Intermediate

Dynamically Configuring Packages
Mike Davis
Intermediate

Full Text Searching – A Guide for DBAs & Devs
Robert Cain
Beginner

Introduction to Data Warehousing / BI
Robert Cain
Beginner

Introduction to Performance Tuning
Mike Femenella
Beginner

Introduction to Performance Tuning
Mike Femenella
Beginner

Introduction to Transactional Replication
Troy Gallant
Beginner

Loading Data In Real Time
Mike Femenella
Intermediate

Off and Running with PowerPivot for Excel 2010
Robert Cain
Beginner

PowerShell for the Data Professional
Aaron Nelson
Intermediate

RESTful Data
Chris Eargle
Beginner

Slowly Changing Dimensions–Done Well.
Julie Smith
Beginner

Solving Real World Problems With DMVs
Whitney Weaver
Intermediate

SQL Server 2008 R2 Overview – Session 1
David Rodriguez
Beginner

SQL Server 2008 R2- BI Drill Down Session 2
David Rodriguez
Beginner

SQL Server 2008 R2- DBA Drill Down Session 3
David Rodriguez
Beginner

SS2008 Data Mining with Excel 2010 and PowerPivot
Mark Tabladillo
Intermediate

Survey of Windows Azure Platform Storage Options
Glen Gordon
Intermediate

The Art and Science of Data Modeling
Audrey Hammonds
Beginner

Tuna Helper for SQL Server DBA’s
Janis Griffin
Intermediate

Using Event Handlers in SSIS for Auditing and Noti
Mike Davis
Intermediate

Virtualize This!
Aaron Nelson
Beginner

Wait-Time Based SQL Server Performance Management
Janis Griffin
Intermediate

When GEO meets SQL: Hotwiring Data to Locations
Michael Clifford
Beginner

#TSQL2sDay 003: Maslow and relational design

Rob Farley is hosting the third installment of TSQL Tuesday, and it’s a fun one: relationships (in honor of Valentine’s Day).   While I’m not currently in much of a mood to opine on the virtues of love and databases, I did think I wanted to post something a bit more esoteric this time.  Not many of you may know that I don’t have a formal background in Information Technology (some of my more sarcastic friends just held their tongues at that one); I actually have a Master of Arts in Communication, and a Master’s of Education in Instructional Technology.  I tripped into IT when I failed my comprehensive exams for the doctoral program in Speech Communication at the University of Georgia.  Awful time, but ultimately one of the best things to ever happen to me.

Anyway, why is this relevant?  Because the goal of this post is to attempt to extend one of the more famous models of social psychology and communication to database design; bear with me (I’m assuming that many of you either have no background in social psych or slept through it), but I’m hoping that this extension to the metaphor will benefit you in terms of your application design.

Maslow: the crash course.

The following is a BRIEF introduction to the theory; if you want more details, Wikipedia is your friend. In a nutshell, Abraham Maslow proposed that humans, as a social animal, were driven to fulfill certain basic needs in a quest for self-actualization or enlightenment.  He proposed a pyramidic model of five sets (or stages) of these needs, with the four lowest ones being required to achieve before attempting the fifth; few people ever attain the fifth level, but the quest to reach that is part of our collective experience.  I’ve defined the five stages below:

maslows_hierarchy_of_needssvg Physiological:

The basic requirements for human existence; food, water, etc.

Safety:

This often translates into security, but it’s different than the term we use in information technology careers; safety is the ability to acquire and maintain goods for ongoing existence.  The Physiological elements are immediate needs; Safety elements are the ability to fulfill those immediate needs at a future date.

Social:

Where do we belong?  How do we interact with others who need us (and we need)?  What is our role, and how does that affect our definition of the self?

Esteem:

Esteem stems from the social need; once our relationship with others has been established, we can truly begin to define ourselves and the virtue of our importance in the world.

Self-Actualization:

Self-actualization is the ultimate fulfillment of one’s potential; to be what one is, without need for constant reinforcement from other beings, yet able to exist in harmony with purpose.  Few people have ever attained this stage, but as stated before, the quest to reach the top of the pyramid drives human development.

So what does this mean to the database designer?

Why is all of this important?  This is not a perfect analogy, but if we extend Maslow’s model to the area of database design, some interesting questions arise (particularly in the third and fourth stages, which is why I felt like this point would be relevant to the TSQL Tuesday challenge of relationships).  Let’s take each stage, and step through them again.

Physiological:

While applications don’t have physiological needs, they DO require certain basic elements for long term survival.  Questions to consider at this stage are things like: How much space will I need?  What are the server requirements?  Can my database live in cloud or a mobile device?   What sort of I/O concerns do I have?

Safety:

Recall that safety is NOT security (in terms of who has access to the data), but it is security in terms of long-term survival of the application.  Is the database you’re designing intended for a long-term project, or is it “throw-away” code?  Have you designed it in such a way so that it’s easy to replace without impacting the dependent application?

Social:

Speaking of dependent applications (and herein lies the relationship aspect of this post), is your database application designed so that it is loosely related and decoupled from the application?  Does the database fulfill the needed role within the relationship (data storage), without treading too far into business logic?  Can the database handle multiple relationships with various applications (UI/reporting/business services).

Esteem:

Closely related to the social nature of the database within the application stack is the need for self-esteem within the database; can the database meet the the needs of the dependent applications WHILE retaining enough information to establish new relationships?  A classic example of this is the lookup table; a database with low self-esteem will only store the enumerated values provided to it by some other application. 

Without the enabling application, the database lacks sufficient internal definition to validate meaning; in practical terms, this means that the database is not decoupled from the application enough to enable the development of alternate accessing applications.  For example, my day job is to reverse engineer vendor databases; few things in the world are more disturbing than a table full of numbers without any sort of category associated with that number.  The application designer decided to store that enumeration in the application; security through obfuscation IS a method of securing your database, but not a very effective one.

A high-self esteem database will store all of the appropriate lookup values (complete with constraints) in order to provide complete validity within the structure.  The database can then be reused by several different applications, without requiring a complete set of business rules to determine those relationships.    The data layer is definitional; the business layer should be procedural.

hal[1] Self-Actualization:

I have to admit that discussing self-actualization in regards to application design makes me think of HAL.  “I’m sorry, Dave….”

To try and stay on track with this metaphor, self-actualization is the basic premise of BI; when your database can start providing you knowledge instead of just data, it has attained the highest level of potential.  Few apps make it that far without requiring substantial redesign, but the ones that do are invaluable to the enterprise they support.

So where are we?

Dunno.  I hope this little exercise made your brain hurt just a bit, and opened up a new metaphor for understanding database design issues within the application stack.   If you have more questions than answers, that’s a good place to be.

SQL Saturday 41 is official!

It’s live; we’re limited to 250 seats, so register now for a great day of training in Atlanta on April 24.  We’re also looking for speakers and sponsors, so please feel free to spread the word.  I’ll continue working on the stub in order to finish the site out, so check back often.

This will be a new challenge for me, since we’re planning on running this by committee (which has both benefits and challenges); I’ll keep you posted as to how that’s working out.

Stay tuned!

Shhhh! SQLSaturday Atlanta 2010 request has been submitted.

We’re looking at April 24 at the Microsoft facility in Alpharetta, GA.  I just submitted the request on the website tonight, so it probably won’t be official for a few days, but I a) needed something to blog about tonight, and b) wanted to get the word out to start some buzz.

Like last year, there will be a waiting list; we’re limited on space, and it will probably book quickly, so keep an eye out on this website for the official announcement.  We’re hoping to have several tracks again, as well as a mixture of experienced speakers and newcomers.

Watch and wait 🙂

We now resume our regularly scheduled programming…

OK, so I haven’t exactly lived up to my promise to keep blogging on a regular basis despite my personal issues.  Sorry.  I’ve been wasting a lot of time lately, just moping around the house.  It’s funny, when you’re depressed, you have all this time on your hands, all this nervous energy, and yet, you don’t get anything done.  I haven’t even changed light bulbs.  I just sat there in the dark, and watched a lot of tv.  I’ve also been reconnecting with friends on Facebook; even though I had previously canceled my account, I realized that I had recently been in touch with a lot of friends, and they’re a support system.

Today, I realized that I was sitting in a dark house, and I had a ladder and a light bulb.  I decided that I was going to do something productive today, and I changed the damn light bulb.  I also realized that I could write a blog post, and that I needed to commit to doing something productive every day, or I was going to slide slowly into the abyss.

So, here we are, you and me, and this blog post that isn’t going anywhere.  Think of it as a public commitment; I vow to blog at least once every week.  I need to reconnect with people, and this blog had been a great vehicle for that in the past, and it will be one for me again.  So, if you’ve hung around waiting on something to happen… it’s happening.