Editor’s Note: Originally published on the Evolver blog, this post is a fun look at searching best practices—always a hot topic for our readers. We thought we’d share Mimi’s and Terry’s insights here, too.
In their award-winning 2010 music video, the band OK Go playfully executed the ultimate modern-day version of the Rube Goldberg machine. Rube’s machines are a staple of geek America, inspiring contests, games, and museum exhibits, as well appearing in cameo roles in such movies as Pee-wee's Big Adventure and Robots to name a couple.
For the uninitiated, inventor and cartoonist Reuben Lucius “Rube” Goldberg (1883 – 1970) was famous for designing overly complicated machines that fixed everyday problems with wit and madness. Even though Rube died nearly 47 years ago, chances are you may have Rube wannabes alive and well and hard at work in your Relativity workspaces.
Eliminate Complicated Searches in Relativity; Minimize Performance Repercussions
No document review is complete without the clever user armed with their impossibly complex nested searches, pushing the operational boundaries of SQL Server. No matter your role in the review project, poorly constructed compound searches affect you with their performance- and resource-hogging behavior. Here’s how a few simple tweaks can eliminate the laboriously contrived Rube-esque saved searches hiding in your workspace.
First a Note from Relativity Documentation
Relativity’s documentation on searching explains nested searches by first laying the foundation comparison to a tree—complete with metaphors for “root,” “branch,” and “leaf”—to better understand how to construct effective complex searches. Chances are good that many members of your review team are unfamiliar with this documentation, a valuable resource including interactive tutorials.
If nested searches are to be a fact of life for Relativity users, we introduce the following information and tips that we’re calling “Reduce the Rube Factor” (RRF).
RRF Tip #1: Volume, Volume, Volume
The KISS (keep it simple, stupid) principle applies: reduce the number of searches in your workspaces.
Without getting too far afield into a discussion of static verses dynamic searches, consider, whenever possible, substituting static tagging or lists as search conditions in lieu of including nested searches in your query. This simplification and volume-limiting technique will result in faster return of results, especially in very large Relativity workspaces.
Are any of your searches overlapping? Are you creating multiple searches for a single field when you could have a single search querying for multiple choices for that field? Pruning to eliminate redundant searches or combining searches will help!
Remember: Trimming Leaf and Branch Searches can speed up result displays for Root Searches
With the first-level weeding completed through simplification and volume reduction, we refer you to Relativity’s explanatory framework wherein Relativity likens the search architecture to Root, Branch, and Leaf searches, offering guidance for complex saved searches (see “Searching behind the scenes” – System Guides). Fine reading for the insomniac.
Only have time for the highlights? Here are noteworthy search definitions from Relativity:
- Root: the search you’re running in Relativity.
- Branch: a saved search that relies upon the output of a Leaf Search and is then referenced by the search you’re running (the Root Search).
- Leaf: a saved search that does not rely on the output of another saved search but is referenced by a Branch Search.
RRF Tip #2: Stop Misusing “Is Like” Operator in Searches
We all have that friend or coworker that is impossibly longwinded. Any “Is Like” search executes just like this person, taking you all the way from the beginning of time (first record/row) up to present (last record/row).
More About the “Is Like” Operator
The “Is Like” operator is an overlooked villain when allied with the Rube wannabes on your review team, and can bring your SQL to its knees.
Why? To execute an “Is Like” search, Relativity has to run the query through every record in the database table without the benefit of an index. This is extremely resource intensive. Also, did you know the “Is Like” operator prevents other queries from editing the table until it completes? This, too, can negatively affect performance.
How is it fixed? Relativity recommends using the “Contains” operator rather than “Is Like” whenever possible.
So, when does “Is Like” work? Limit to running against a subset of data; for example, “Relativity Native type is like Excel” on a production set.
Don’t believe us? In off hours, try it for yourself. Use “Is Like” across a heavily populated field like Control Number, as we witnessed on a recent project … !
RRF Tip #3: Avoid Family Problems in Search Queries
Including relational groups (families, email threads, dupes, etc.) adds run time for searches. Use this option sparingly, especially for lower Branch and Leaf Searches.
This is an oft-overlooked time-saver by even the most careful Relativity users. Homer Simpson says it best: “I believe that children are our future. Unless we stop them now.”
RRF Tip #4: Consider Sort Order
The specter of Rube haunts even the most clever e-discovery pros when using an unnecessarily complex sort order. Relativity sorts by selected fields before search results display.
All that simplification and trimming up to this point is for naught if the display of Root Search results is delayed due to a complex multi-level sort. Use an existing view containing the desired sort order to simplify things.
Note: Under no circumstances should your mad scientist user be adding sort orders to Branch and Leaf Searches (their raison d’etre is simply as output feeders to the Root Search).
We wish you safe, happy, and speedy searching!
Mimi Singh is the associate general counsel and director of eDiscovery Consulting for Evolver, Inc. Recognized as Relativity's first Stellar Women in e-Discovery, she is a certified Relativity Master leveraging Relativity Analytics in providing full-service e-discovery lifecycle consulting and project management relating to identifying, preserving, processing, reviewing, and producing in an efficient and cost-effective manner. Prior to Evolver, Mimi worked for corporations and law firms where for over a decade she delivered e-discovery strategic design and implementation counseling support through all stages of the EDRM. She earned a Master of Laws (LL.M.) from New York University School of Law and a J.D. from Stanford University School of Law. Mimi publishes and speaks frequently on e-discovery and legal technology issues and solutions including a conversation with Judge David J. Waxse on proportionality and Relativity collaborations: “Five Spreadsheet Redactions Headaches and How to Relieve Them” and a panel to discuss “Redactions Managed Right: A Practical Navigation Roadmap for Litigation Support & Counsel.” Come hear her speak at this year’s Relativity Fest!
