Join Us!

Notifications
Clear all

E-Discovery and SQL  

  RSS
toppock123
(@toppock123)
New Member

I am currently going through the interview process for an E-Discovery job and have an interview coming up based on SQL and programming skills. I have had 1 or 2 in the past and have not got past the first stage due to my lack of SQL experience. As a result of this, I have taken the time to learn as much as possible in my free time and have had some exposure in my current job to it.

My problem is, I have no idea how SQL fits into an E-Discovery role. I understand that the ESI will come in very large sets at times, but is this the only reason for it? The skill seems to be very highly desired but there seems to be no logical explanation as to why it is needed or how it is applied.

If I could get an explanation as to how SQL fits into the role, it can hopefully enable me to better understand how this skill is used and can gear my preparation towards a certain aspect.

Thanks in advance.

Quote
Posted : 19/01/2014 10:23 pm
Passmark
(@passmark)
Active Member

Databases are used everywhere and SQL is the common form of database.

They are used by browsers, for local storage, to store interesting data like URL histories (using SQLLite).
They are used by companies on their servers to hold customer information, order information, product information, employee information, etc..
They are used on the web to dynamically create web pages on the fly.
They are even used in computer games to store in game data.

Of course there are many other data structures in use, and may other data base languages. SQL is just the one you come across most often.

ReplyQuote
Posted : 20/01/2014 4:11 am
Sydney34
(@sydney34)
New Member

SQL gets used a lot in eDiscovery. It's not so much used in relation to the ESI, but rather, in the eDiscovery tools used to manage the ESI.

A lot of the eDiscovery tools will rip out meta data from potential evidence and store it in a database somewhere. It's a common occurence though, that a particular eDiscovery tool won't do exactly what a legal team wants to do, and having someone that can delve into the back end of the eDiscovery tool to report on or manipulate the data directly (using SQL) is very very useful.

ReplyQuote
Posted : 20/01/2014 10:01 am
toppock123
(@toppock123)
New Member

Sydney34, this makes a lot of sense - exactly what I needed. I have asked around other places and have discovered that the back end of the particular software used most is highly customisable using SQL. At least now I know how to apply what I have learned so far.

Thanks again.

ReplyQuote
Posted : 20/01/2014 2:41 pm
Patrick4n6
(@patrick4n6)
Senior Member

I can write great queries, do BCNF in one pass, and administer a database, but in 6 years of eDisco and 13 years in digital evidence I've never had to do it for anything related to the core job. (I had to do a little code for a case management tool.) Major eDisco tool manufacturers aren't going to let you into the SQL backend of their apps. And yet I still see this in the job postings. Go figure.

SQL is more a Data Analytics skill than an eDisco skill. I suspect that your recruiter or hiring manager is simply clueless and re-using some other job description. Either that or the job is not a pureplay eDisco job. The extended team I work with has data analytics people, but they have no part in the eDisco process.

ReplyQuote
Posted : 22/01/2014 10:07 am
Sydney34
(@sydney34)
New Member

Those are good points Tony. I guess the kinds of things I've been asked to do are things like

Custom reporting directly from the database

Custom importing/ exporting data into/ from the database

Custom search/ tagging in the database

These generally happen because the eDiscovery tool isn't flexible enough (for the legal team's mad and crazy requests), or is struggling to handle the size of the document population (e.g. importing might take 2 days to complete using the provided tools, whereas custom SQL to write the data directly into the database takes 30 minutes).

I guess there are lots of reasons to not bend the rules and only use the software as provided, but people can and do tinker with the back ends.

A lot of tools use standard RDMS's. In these instances, there's not that much they can do to keep their users out! That said, tinkering can involve a bit of having to work out for yourself how the database relationships fit together. And it goes without saying (thus I must now say it), if you muck the database up, your eDiscovery vendor may not be that forthcoming in helping you fix it!

Also, I know there is one tool that uses Microsoft Access (Ringtail) for exchanging discovery data (most tools I see use some kind of .csv/ json file instead), so SQL might come into play there if you have to manipulate data being exchanged.

ReplyQuote
Posted : 24/01/2014 8:56 am
96hz
 96hz
(@96hz)
Active Member

Custom reporting directly from the database

Custom importing/ exporting data into/ from the database

Custom search/ tagging in the database.

Exactly, SQL + a scripting language, essential for the more technical ED roles.

ReplyQuote
Posted : 25/01/2014 1:19 am
Share: