Delete from TbPerps Where ...
Here's a snippet from the Strategy Page with a buried nugget: a battlefield account of terrorists fighting a virtual enemy. In describing the never-ending strikes against targets in Fallujah, it describes the ongoing operation in a curious way:
U.S. troops maintain databases of who they are fighting, the better to pick targets for raids or surveillance. ... Daily, the smart bombs blow apart houses used by the gangs for housing, headquarters or ammo dumps. The gangs have become very paranoid, believing there are spies everywhere. They are correct, but some of the most revealing spies are unreachable. Above Fallujah, U.S. warplanes and UAVs circle constantly, able to clearly view what is below, day or night. The telescopic bomb sights allow pilots to see what kind of weapon people are carrying, or whether women and children are in a crowd. The gangs have learned to never gather in large groups, at least not without plenty of women and children nearby for protection. But that doesn’t always work, for the AC-130 gunships can kill a man without harming someone ten feet away. The gangs fear that the American troops are coming back to Fallujah, and they are right. The not-so-secret plan is to go back in before the end of the year, kill all gang members that can be found, and then turn the city over to Iraqi troops, composed mostly of Shia and Kurds.
For the insurgents, the real enemy, the brain that pulls the trigger, is an abstract structure called a database. It tracks links between individuals, noting not only who knows who, but who is subordinate to whom. For example, A may have two subordinates, B and C. E and F may report to B and so on. Theoretically, you can store all this in a single narrow, but long table that looks like this:
Self-join |
Some sample data would look like this. When you unrolled it, you'd have a network of nodes which indicated the relationship between operatives that you are fighting. There would be multiple paths to most nodes, though the highly protected masterminds would have only a few, for security reasons.
PerpID | Name | Reports To |
1 | Big Cheese | 1 |
2 | IED Setter | 1 |
3 | Runner | 1 |
4 | IED Detonator | 2 |
This simple structure conceals a number of difficulties. The principal one is that the data in the foreign key column (Reports To) is changing all the time. People move within an organization and report to different people over time. They are tasked differently from one day to the next. A terrorists "boss" and "subordinates" will change, just our work relationships change. Since the relationship, or association determines where the JDAM falls, choosing your friends in Fallujah is an important task. From the enemy's point of view every connection is fraught with danger. Hook up your network to the wrong guy and you sleep with the fishes. But the worst aspect of it is that killing individual US soldiers doesn't really solve anything unless you can take apart the system that is feeding information into the databases.
In this circumstance, many of the traditional military metrics are totally upset. Weight of firepower, that is the amount of tonnage your attack aircraft can carry, becomes an irrelevant factor. The hard constraint is information. You are limited by your database. After reading the Strategy Page, I'll never look at a DB engine as an innocent object ever again.
<< Home