gilbane boston 2012: xml and sql: not dead yet
TRANSCRIPT
Content Delivery Decisions for Technology Strategists
Joseph BachanaPresident/Founder, DPCI
Leonor CiarlonePrincipal, LMC Communications
Peter O'KellyPrincipal Analyst, O'Kelly Associates
Thursday, November 29, 201211:40 – 12:40
2
Overall Session Agenda
• Not Dead Yet: The Significant and Sustainable Synergy of XML and SQL
• Convergence of Content Technologies in the Open Source World
• Q&A
3
Agenda: Not Dead Yet
• Synopsis• Complementary concerns– Resources– Relations– Apps– Admin/ops
• Perspectives and reality checks• Recommendations
4
Synopsis: Not Dead Yet
• XML and SQL are, respectively, the global standards for working with document- and Web-oriented information and traditional database management systems (DBMSs)
• However, both are also at least ostensibly under siege, with, e.g., – Some application developers shifting their focus to
JavaScript (and JSON, the JavaScript Object Notation)– Many software product marketing people and investors
touting the professed power of "NoSQL" (and “NewSQL”) systems
5
Synopsis: Not Dead Yet
• The stakes are strategic, with ever-expanding compliance and competitive considerations, and with compelling new opportunities based on– Big data– Cloud services– HTML5 clients– Mobile devices
• [Spoiler alert: neither XML nor SQL is going away]
6
Agenda: Not Dead Yet
• Synopsis• Complementary concerns• Perspectives and reality checks• Recommendations
7
Resources and Relations
• A digital information item dichotomy – Resources (~unstructured information): “content”
• Digital artifacts optimized to convey stories– Organized in terms of narrative, hierarchy, and sequence
• Examples: books, magazines, documents (e.g., PDF, Word), Web pages, XBRL documents, video, hypertext…
– Relations (~structured information): “data”• Application-independent descriptions of real-world things
and relationships• Examples: business domain databases (e.g., customer,
sales, HR…), data.com, wikidata.org…
8
A Big-Picture Framework
Resource RelationW
ord
docs
DITA
doc
s
XBRL
doc
s
PDF d
ocs
Oper
ation
al d
b
Desk
top
db
9
Separation of Concerns
• Back to basics– XML (with namespaces, XSD, XPath, XQuery, XSLT, …) for resources
• Presentation• Structure• Behavior
– SQL for relations• Application/data independence• Logical/physical data independence
• Related services for both information domains: identity, authentication, authorization, logging, transactions, indexing, dynamic storage optimization…– Ideally handled by underlying information management systems
rather than applications
10
Complementary Concerns
Apps
Relation
Admin/Ops
Resource
11
Agenda: Not Dead Yet
• Synopsis• Complementary concerns• Perspectives and reality checks• Recommendations
12
Resource Perspectives
Apps
Relation
Admin/Ops
Resource
• Every useful thing is a resource (document/page)• SQL is for uncreative and obsessive data nerds• Apps are interactive/compound resources• Admin/ops: somebody else’s problem
13
Relation Perspectives
Apps
Admin/Ops
Resource
Relation
• Relations can describe all useful things• Resource: XML compound data type instance• Apps are interfaces for relation interaction• Admin/ops: somebody else’s problem
14
Application Perspectives
Apps
Relation
Admin/Ops
Resource
• Anything that’s not an app is just for archival• Resource => XML => verbose/unwieldy• Relation => SQL => impedance mismatch• Admin/ops: somebody else’s problem
15
Admin/Ops PerspectivesApps
RelationResource
Admin/Ops
• Robust/scalable admin/ops or we all go to jail• Resource => XML => eXtra Mondo Large files• Relation => SQL => a DBMS trying to be an OS• Apps: most likely to break infrastructure
16
Vendor Marketing Perspectives
• Resources: a Web-centric approach fixes everything
• Relations: NoSQL fixes everything
• Apps: JSON fixes everything• Admin/ops: the cloud fixes
everything
17
A Reality Check
“Everything should be made as simple as possible, but no simpler.”
18
Modeling AbstractionsResources Relations
Conceptual Documents and links; documents focused primarily on narrative,
hierarchy, and sequence
Entities, attributes, relationships, and identifiers
Logical Model: hypertextLanguage: XQuery (ideally…)
Model: extended relationalLanguage: SQL
Physical Indexing (e.g., scalar data types, XML, and full-text), locking and isolation levels (for transactions), federation, replication/synchronization, in-memory
databases, columnar storage, table spaces, caching, and more
19
A Resource Reality Check
• XML has some idiosyncrasies, but it’s beyond good-enough for its primary target domain, and it’s here to stay– Indeed, XML is, in some respects, just getting started
• XQuery, in particular, is exceptionally powerful
• But XML should be made invisible to information architects, application developers, and admin/ops– They should work with tools that support their
respective levels of abstraction, but that still leverage XML when appropriate
20
“A DBMS is good for my XML?”
21
A Relation Reality Check
• SQL has some idiosyncrasies, but it’s beyond good-enough for its primary target domain, and it’s here to stay– Being anti-SQL, ultimately, is being anti-set theory
• Not a good bet when you’re describing sets of things
• But SQL should be made invisible to information architects, application developers, and admin/ops– They should work with tools that support their
respective levels of abstraction, but that still leverage SQL when appropriate
22
XML and SQL
• XML and SQL are sustainably complementary– When used appropriately
• XQuery was designed – by a team including one of SQL’s creators – to complement SQL
• The market-leading RDBMSs can automatically ingest and generate XML
• Some leading XML servers are adding SQL support
23
An App Perspective Reality Check
• The dreaded “impedance mismatch” is mostly a consequence of inadequate programming languages and tools
• Reverting to a programs-have-files perspective means ignoring decades of software engineering evolution
• Using JavaScript doesn’t have to preclude the effective use of XML and SQL– But tools that don’t entail major compromises are only
now starting to appear
24
An Admin/Ops Reality Check
• DBMS evolution isn’t done yet– Multi-model DBMSs are now the enterprise norm• Including subsystems for XML, file steaming, spatial
data, and more
– Automatic “sharding”• New extensions to logical/physical database
independence and database optimization
– A leading indicator: watch what Google does with SQL (or “SQL-like” approaches) in BigQuery and Spanner
25
Agenda: Not Dead Yet
• Synopsis• Complementary concerns• Perspectives and reality checks• Recommendations
26
Recommendations
• Build consensus and establish clear criteria for what to use when (and how)– Otherwise people will often default to the tools
and technologies with which they’re most familiar• And/or the most fun or résumé-enhancing
– Best practices start with effective modeling and query formulation skills• Reminder: XML and SQL should be invisible to most of
the people who benefit from using them
27
Recommendations
• Only invest in tools that don’t dumb-down XML or SQL DBMS usage patterns– RDBMS and XDBMS are exceptionally powerful• But not when they’re demoted to serve as basic file
systems
– Many advocates of “NoSQL/NewSQL” systems have large collections of simplifying assumptions• Sometimes going beyond “… as simple as possible”
– With major compromises and trade-offs that are sometimes not fully understood until far into a project lifecycle
28
Recommendations
• Start preparing now to fully leverage advances such as – Pervasive beyond-the-basics hypertext– Multi-model DBMSs that apply XML/SQL synergy• Especially high-performance XQuery/SQL integration
– Don’t discount the possibility that the DBMS “usual suspects” (commercial and open source) will eventually provide the most effective XML + SQL products/services
29
Recap: Not Dead Yet
• XML and SQL are – and will continue to be – respectively, the global standards for working with document- and Web-oriented information and traditional DBMSs– Although they will ideally be invisible to most people
• Many of the alleged successors to XML- and SQL-related technologies are more complementary than competitive– JavaScript tools can productively coexist with XQuery and SQL,
for example– Most “NoSQL” and “NewSQL” developments are primarily
focused on the physical database layer, and aren’t in conflict with evolving XML and SQL DBMSs
30
Recap: Not Dead Yet
• The stakes are strategic, with ever-expanding compliance and competitive considerations, and with compelling new opportunities – Which are likely to accelerate rather than derail
XML and SQL market momentum• This is an opportune time to build consensus
on and skills in related techniques and tools
31
Q&A