Follow ruthbrarian on Twitter GitLab Connect with me on LinkedIn Subscribe in RSS

Mennonites don’t vote.

That’s what I heard growing up. Not that I was raised Mennonite, mind, but even before I knew enough of the beliefs that I knew I wanted to be one, I knew this one fact about them.

Of course, like any “fact” about Mennonites…it depends.

But it’s definitely a part of our history and our spiritual heritage. My husband says we’ve lost our way, but he still votes. I’m not sure I agree with him about where we lost the way though.

The State

First, let me explain why Mennonites don’t vote. It’s because we, more than many religious groups I think (aka why I ended up with Mennonites), understand exactly what the State is. The State is not moral. The State is never moral. The State is never Good.1 The State derives its authority from an underlying threat of violence, too often realized. Whether it’s taxation through the threat of imprisonment or violence if we do not pay,2 violence involved in taking this land in the first place, violence in the name of keeping us “safe” here. This is what State does.

And this is something which Mennonites/Anabaptists recognized from early on. In not baptising their infants, they did not enroll their infants in state registers. They defied state conscription for wars. They did not do this because they feared dying in those wars. If you think that for a second, lemme drop a copy of the Martyr’s Mirror in your lap.

Within the State, therefore, the Mennonite/Anabaptist allowed themselves to die. Whether at the hands of Turk (nope) or European (hey great guess!), they didn’t raise their own hands to stop it.3

The Mennonite in America

When they got to America, Mennonites (and Amish and other Anabaptists) mostly went into seclusion. After a few centuries of *points at Martyr’s Mirror*, they were really not into engaging much at all. And I think, here, they failed. Not because they wouldn’t support the State. But because when they got here, they immediately became engaged in a completely different way with the State.

In Europe, the land was European. The Mennonites were European. They were simply living where they and their forebears and lived, or moving around in areas which had always, historically, belonged to them and to people like them. In coming to America, the Mennonites took land for which other Europeans had committed the beginning of a genocide. Just like the rest of Americans, they grew and moved West, and more and more indigenous inhabitants were slaughtered to make way for them. And there’s that passive voice…

They saw themselves as disconnected. They were not the State. They were not actively slaughtering. They would even give up their own lives, if attacked. But that did not make them somehow innocent in all this. In America, they became colonizers even if not a single one ever took a Native life.4

And as a part of not being a part of that State, most shunned participation by not actually voting.5 Obviously it’d have been the white dudes for a lot of that time, but they definitely owned property and could’ve voted from early on.6

I think most were earnest and sincere in their decision. I don’t think they did it as an elaborate charade. They had identified something TRUE about the State and they didn’t want any part in it. Let the State kill them, if it had to. They told their children stories of how it had happened before. They told their children it might happen again. They accepted it.

Why I Vote

What I think that they didn’t identify, perhaps because of the models and frameworks from which they had come, is that they were always already involved in this State, in these United States. When the State has disenfranchised one—whether through being a fiefdom or revoking one’s right to a vote through centuries of ongoing suppression of non-White US voters—I think there is still an argument to be made that one can be separate from that State and from that State’s actions. We White American Mennonites? Even the ones who still follow a plain path? We are not that. We are not peasants. We are not disenfranchised. We are not rejected by that State.

And so, I find myself a citizen of a State which takes many actions on my behalf. Some of them are actually good. Some? Heinous.

If I find myself in a place where I see that there are two main paths right now for how that State will be controlled? Then I face two choices. The first is whether or not I can pretend that I am somehow divorced from this legacy, through virtue of my beliefs or my community. I can’t pretend that. I can’t lie to myself about that. So then, I ask whether I can do anything to direct which path it will go down. I can make a statement, at least. Even if my state goes red and my vote “doesn’t really count,” I can say that I thought this other path was not as bad. I thought this other path was less destructive. And I took an action which I hoped might divert it along a slightly better path.

And I am not making that choice just for me. I think we sometimes do a good job convincing ourselves that we would be willing to die, if it came to that. Perhaps we would. Perhaps that Mirror is good for more than flattening literally any crease you could ever have in anything, try it. Perhaps it teaches us that we can make that ultimate personal decision. But it’s not just our decision for ourselves. When I weigh the places where candidates differ, I cannot help coming to the conclusion that one would harm fewer. And so, I vote. And so I will always vote.

Where I Think They Got It Right

I think the early Mennonites were onto something though. I think they were onto something which other modern Christians and even other protest voters weren’t necessarily. The State is violence. It will never not be that. It has never not been that. No truly Good person will ever be able to lead a State. Some will be better-intentioned and some worse-intentioned. Some will cause more harm and some less. Some will effect changes from within.

The State will never be our Salvation. None will ever become a vehicle for living out Gospel. Any State is incapable of allying with Gospel. Because Gospel, as we read it, is entirely incompatible with the violence which every State requires to survive. It is incapable of allying itself with State.

So we look for Gospel elsewhere. We do it through other means. But we cannot pretend that we are somehow separate, here, from State as our spiritual ancestors were in their Radical Reformation-era European States. That is not our 21st-century Mennonite reality. Perhaps it may be again. But it is not now.

This post is not political science. This is theology through the lens of a particular history and, more importantly, how a particular group tells ourselves that history. And it’s awkwardly-done theology, at best. But this is also my best try at laying out why I am a Mennonite who votes.


1. I would allow that some societies can be much closer to Good than the State. I think it is possible for humans to create loving and mutually-beneficial communities both in areas under State control (which is what I think our spiritual ancestors sought to do) and in Stateless regions. I also don’t claim that we’re the only group who sees this, but among American Christianity, I’ve rarely found a church which doesn’t have a flag… except most (MOST) Mennonite ones (I’m looking at you and tightening my lips, though, Allegheny). back

2. Super pro paying taxes except that there’s the whole state violence thing (beyond war) which far too great a % of my taxes go toward. back

3. Let’s not talk about Münster. Ok, let’s mention Münster but note that wasn’t a repeated historical trait. back

4. And I’m not naïve enough to think that’s true. back

5. This can get super-performative, supporting the tobacco lobby but still not voting themselves. back

6. Some owned slaves. We can’t get out of any of this by pretending it didn’t happen. back

When writing my introduction to SQL, I included sample queries that all dealt with the same hypothetical database. The database wasn’t especially fancy or well-planned, it just had a book’s title, location, publisher, and publication year. While you could read it and imagine the query, it didn’t give any hands-on experience, which I’ve found is the best way to learn.

Rather than expect you to set up a database, I used a site called SQLFiddle to make a version of this hypothetical database you can practice on. The database should be loaded at that link. You can enter queries in the right-hand panel. Start by pasting in some of the code farther down in this post.

Sample database

If SQLFiddle doesn’t load the sample database/table, you can copy it from below and paste it in, then click “Build Schema” so SQLFiddle can analyze it for you. This query will also create a table in an existing MySQL database.

Sample Queries

Get all titles where book was published in 2015:

SELECT title
FROM books
WHERE publication_date = '2015';

Get the title where it was published in 2015 by “Simon & Shuster”:

SELECT title
FROM books
WHERE publication_date = '2015'
AND publisher = 'Simon & Shuster';

Same query taking into account that data-entry standards may differ:

SELECT title
FROM books
WHERE publication_date = '2015'
AND (publisher = 'Simon & Shuster' OR publisher='Simon and Shuster');

Find books published in 2015 but somehow not shelved in New:

SELECT title
FROM books
WHERE publication_date = '2015'
AND NOT location = 'new';

Find books that are in New OR were published in 2015. Include their location & publication date and sort them by year. This would let you check whether all 2015 books are where they should be and whether any earlier books are still in New.

SELECT title, location, publication_date
FROM books
WHERE publication_date = '2015'
OR location = 'new'
ORDER BY publication_date;

Now try your own!

Update! This post has been adapted into Spanish with permission by Profesor Jose A. Senso at the University of Granada.

After August’s local Code4Lib meetup and SAA meeting, I’ve begun to consider blogging more about technical subjects. The biggest reason I haven’t so far is the fear of not being comprehensive enough or being too wordy. But if you want comprehensive, I suggest getting O’Reilly books and/or Database Design for Mere Mortals.1 And I’ve accepted I’m going to be wordy…this isn’t my formal work documentation style, this style assumes we’re all still figuring stuff out and tries to be thorough. Some will be beginner stuff and some intermediate. Today is an introduction to SQL written for the people who are already database searching experts—librarians.2

Several years ago, a reference coworker with some technical aptitude sat me down and asked me what SQL was about and whether she could ever learn it. My answer was that, knowing what I did of her work, she probably wouldn’t need to know anything about SQL for her job. But yes, I did believe she could learn it. I think librarians, particularly the ones who spend the most time in subscription databases, have the right mindset to work with SQL.

So if she doesn’t need to learn about it, when might it be appropriate for a librarian to learn SQL?

Whether you need to know it depends on how deeply you have to dive into the software and systems that support the library’s work and what they run on. For example, at my place of work we have a MySQL database where we hold metadata before turning it into Fedora objects. I use SQL to extract that metadata into spreadsheets and then run update queries to improve that metadata. A lot of the work done around migrating Archivists’ Toolkit installations to ArchivesSpace involved digging into both databases. And it translates. Understanding SQL may help you better understand an API for a service you’re trying to set up. I’d definitely recommend it for metadata types and digital archives/collections types.

Preliminaries: Things to Know But Not Worry About

SQL has dialects based on the type of setup you’re using. What I’m going to be talking about relates to MySQL databases. You may be using a PostgreSQL or SQL Server. You can look up dialectical differences here and find threads on various forums talking about why MySQL doesn’t support FULL OUTER JOIN, but my advice for starting out is not to worry too much about it. Most of it’s the same.

Why backticks? Why only sometimes? When looking around, you may see SQL written as SELECT `comment_author` FROM `wp_comments`. In MySQL, backticks are used to to indicate that the phrase is some kind of identifier: a database name, a table name, or a field name. It lets MySQL support spaces in field or table names3 and lets you use a reserved word like `from` as a name without causing errors. If you’re not worried about those use cases, you don’t need to use it but you always can. I’m going to use them in my prose so that you know I’m talking about a database/table/field but not in my code examples because I generally write SQL without them.

Why are Librarians Suited to SQL?

Because querying information is what we do. You’ve thought “ok this is what I want, now where do I go to get it and what should I put into the fields?” In many cases we’re already doing mediated queries which are functionally indistinguishable from SQL. When you’re saying that you want to search for Article from a database where a Title is “Name of the title,” what you’re doing is essentially the same as writing a SQL query. Reports used to get data from or update data in your ILS use the same type of querying.

You know how to do this. All you need is the language to express it. I have faith. Let’s do this.

Get to Know Your Database

Assuming you’ve got access to run queries4, now you need to know what you’re querying. You know how you get familiar with running a JSTOR search? You know how to do basic searches and when an advanced search might be needed. You’re familiar with the fields which you can conveniently access from drop-downs or checkboxes. And even if you’re not familiar, you can figure it out because it’s all there on the page. While SQL databases may not be quite as up-front about what’s in them (and some do have composition windows that lets you use fields as drop-downs), it’s still easy to get that information.

Databases contain multiple tables, generally divided by the type of data they store, like `omeka_options` or `accessions`. Tables then contain fields, which you can think of as being like an Excel column. In a very simple table, one field might be for a book’s title, the next for its date of publication, the next for its table of contents, etc..

There are two ways to find out what tables are in your database and what fields those contain and a third that may help you get a real idea of what’s in those tables.

Table Information Through the Interface

First, most interfaces actually give you a visual display of the tables and fields.. If I go into phpMyAdmin as seen below, I can click on a database and see a list of its tables plus other info about the tables which I may not need to know if I’m not doing high-level work.

A list of tables in a MySQL database

Now if I click on a table, I can see a list of its fields (again, think column names) as well as the first set of records in the fields. This gives me a good idea of what the data actually looks like.

What fields in a table look like

What’s up at the top of this? That’s right, phpMyAdmin is actually using a SQL query to generate this page. Zooming in, we see:

Zooming in on how phpMyAdmin is actually generating the fields

Querying for Detailed Table Information

Second, we can get this info by running MySQL queries. If we run:


our client should reply with a list of all the tables in the database. Now we know table names!

Then we need to know what the field names are and maybe a bit about what kind of info is in the fields. Using the table name, we run:

DESCRIBE omeka_options;

and get

A detailed look at how the fields are made

The first column is field names. The second tells us what kind of info is in the fields. You can look up what each of those mean. These two are the most important (along with key) when you’re starting out. The third tells us if it’s ever allowed to be empty or NULL. The fourth tells us about whether any of these are keys and what kind. Keys are a whole thing about which I should probably write a short post, but you don’t need them for simple queries. The fifth tells us if there is any default value, such as “false” or “true,” but this doesn’t have any. And the final column tells us anything additional— in this case we know that the ID auto-increments.

Querying for Example Table Data

Remember when I zoomed in above to show that phpMyAdmin was using a query to generate data? The most basic way to get an example of what’s in the table is to run:


I’ll explain the elements that make up this query below, but the result should be the first 25 entries from the table. I can look through it to see things like if a field called `location` uses the value “new” when a book is on the new books shelf, “sl2” when it’s on stack level 2, etc.. This will help me construct queries later.

Write, Write, Write

When getting started, it can be easiest to do this using a pencil and scratch paper, but you can also make notes in a document on your computer as you figure it out.

You’re querying because you WANT something. You probably want information. Maybe you want to build a spreadsheet with some info. Maybe you want a specific list of titles that match X. Maybe you want an article title and the DOI you can use to get to that article title.

Despite having used SQL for around 8 years now, I still start writing things down when I’m doing really complex stuff. Use what you’ve written as you walk through the section about constructing query syntax. Make notes on it as you understand better how you’d express it in the SQL syntax.

Now We Query

Finally! This is what we’ve been building toward. Let’s walk through the syntax by levels of complexity in the query. Every query needs two basic clauses: a SELECT and a FROM.

SELECT — does what it sounds like. SELECT is just going to pull out data, as opposed to commands which change the data: UPDATE or DELETE or INSERT. Most of the time, you’ll be listing field names you want to select, like `title`. Separate multiple fields with commas. Use a * to select every single field. You can refine a SELECT by starting with * like we did in the query above and then deciding which of those fields you actually want.

FROM — name of the table. Normally that’s just `table_name`, but sometimes it can be `database_name`.`table_name`. See the period? We use periods to join database, table, and field names for specificity in queries. You only do this when you’re going to be searching multiple databases and multiple tables, which we’re not doing there.

The next most common clause in a query is WHERE.

WHERE — introduces the ability to limit what we’re getting. You may only use one WHERE (see AND/OR). Here’s an example query below. It uses WHERE to specify that we only want books published in 2015. Notice we don’t have to SELECT `publication_date` to use it in the query. A query can refer to any field in any table you’re referencing in the query.

SELECT title
FROM books
WHERE publication_date = '2015';

WHERE can use a lot of comparison operators besides the = like < > != <> !< !> <= >=, all of which you can learn more about by searching for “SQL Comparison Operators.” It can also use logical operators, including: LIKE, IS NULL, IS UNIQUE, EXISTS, and BETWEEN. I’m not going to spell it out here, but a search for “SQL Logical Operators” will help you out on this one.

After WHERE, we get AND, OR, and NOT. These are all considered to be part of the WHERE clause as you can’t use them without one.

AND — ah the familiar Boolean search. You may use as many ANDs as necessary to add additional requirements to your search. So you might want the date of publication to be in 2015 AND the publication to be from Simon & Shuster. As with an article database or a catalog, AND is limiting and all restrictions must be met.

SELECT title
FROM books
WHERE publication_date = '2015'
AND publisher = 'Simon & Shuster';

OR — more Boolean. Again, use as many as necessary. Maybe you’re looking for books on the new shelf OR books published in 2015.

SELECT title
FROM books
WHERE publication_date = '2015'
OR location = 'new';

NOT — you knew this was coming, right? But unlike in Boolean, NOT needs to be used with WHERE, AND, or OR to do its negation. Let’s suppose that we’re now looking for books that were published in 2015 but haven’t made it to the new shelf yet!

SELECT title
FROM books
WHERE publication_date = '2015'
AND NOT location = 'new';

This can also be done by simply using the != or <> operators to say location != 'new', but there may be reasons you want to do it this way.

You can also nest AND, OR, and NOT within parenthetical statements. Perhaps we know that the data wasn’t always entered cleanly. So we want something from Simon & Shuster but we know somebody probably wrote it as “Simon and Shuster” at least once. Again, this is pretty similar to other searches we do.

SELECT title
FROM books
WHERE publication_date = '2015'
AND (publisher = 'Simon & Shuster' OR publisher='Simon and Shuster');

Since this is a basic overview and we’ve hit up all the basic elements, let’s move to the two basic ways to control output.

LIMIT — lets you control where you start and stop looking at results. LIMIT 25 is acceptable, but you can also write LIMIT 0,25 (like many programming languages, SQL starts counting at 0). You can then run the query a second time and say LIMIT 26, 50 to get the next 25 results. This is really useful when you only need a sampling of results or when you don’t want to overload the server

In the examples above, phpMyAdmin is automatically adding LIMIT 0, 30 when I don’t put in my own limit. At work, I often do LIMIT 0, 1000 and then 1001, 2000, etc. If server you’re querying gets heavy use or your query is really complex, you probably want to lower that number.

ORDER BY — lets you choose how you get the results. Just like anything referenced in the WHERE clause, it doesn’t actually have to be in the list of fields you’re SELECTing. You can select whether you want it ascending (ASC) or descending (DESC). ASC is default, so you don’t have to add it unless you’re being very intentional.

SELECT title
FROM books
WHERE publication_date = '2015'
OR location = 'new'
ORDER BY publication_date DESC;


That was a lot, so let’s put it together and pare down to the essentials.

  1. To build a SQL query, you first need to know a bit about the database you’re querying from.
  2. Then figure out what it is that you want. Find where the info is in those tables and fields.
  3. Write down your thoughts and refine them as you go.
  4. And finally refine what you wrote down using the section with a basic intro to syntax.

I’m going to write more tutorials in the future, like “how do I get data from two tables?” with companion “what’s a key?”. Most, I think, will be shorter and will refer to this master intro post. I’m open to feedback about style and content. There are a lot of reference sites out there, but that’s not exactly what I’m trying to do here, although I hope this will be a good reference for those who’ve used it. What I hope is that this tutorial made SQL a little less confusing and helped you see that it’s just a way of expressing skills you had all along.

Follow-up Posts on SQL

Footnotes, a.k.a. Rejected Parentheticals

1. If your library has a subscription, many O’Reilly books are available through Safari. Database Design for Mere Mortals was the text we used in my Database Design/Management class at CUA (with Bruce Hulse, I recommend it if you’re a student). back

2. …or archivists, let’s not leave my hybrid-self out! But I’m going to use just the one term. back

3. But why would you do this?? Why?? Just use underscores. back

4. And for the love of all things holy, stick with SELECT queries until you’re really good at SQL and even then always run SELECT to ensure you’ve got things right before running UPDATE or DELETE. back