A three file data base to create a many to many relationship would work but might be a bit of a pain.

Table Titles
title Id| title

Table Tags
Tag Id| Tag

Table Connector
Connection Id| Title Id | Tag Id

The first field in each table would be auto generated.

Maybe access could make a form to handle those tables that would not be too big a pain to fill in.

Many moons ago I had to do something on those lines In Visual Fox Pro, but I doubt anyone but a few people with legacy code use that any more.

I absolutely could do it in a database. I could probably fake something just fine in Excel - in fact, I started to. But what I like about tagging, as implemented in... everything... is the type-it-and-forget-it simplicity.

I think I may actually use Evernote for REALS and copy the test questions in there, as images snipped from the PDF. I can scan the ones I have hard copies of - we have a PDF-scanning copy machine that would make it fast. That would provide some interesting power, and would probably pay off in the long run.

Technically you don't even need a connection ID, unless there's some reason you want to treat the relationship as an entity itself.

However, I'd just put it in a spreadsheet, if I didn't have a DB app to hand.

You are right, but using short meaningless keys makes your appliation run faster and in general is cleaner. "smart keys" should be alternate keys, not primary keys. At least that was the way I was taught. Maybe obsolete now.

And GRis's statement makes me think there may be something out there like that - an old application that would do exactly what Gris wants. Except I can't remember the name of the application so it does not do Gris much fucking good.

using short meaningless keys makes your appliation run faster and in general is cleaner

I think that depends on what you're trying to achieve and what you're trying to achieve it with. We have just had a vendor in telling us to lengthen our keys (as in, number of fields) for better performance, so there you go.

We have just had a vendor in telling us to lengthen our keys

Huh. For what database server?

It's not a database server, it's a content management server. This is one of their recommendations for optimising their content model--don't rely on single field primary keys, but extend to two or three fields.

Of course, there's more of an overlay between you and the data than with just a database server, but you also get tagging and multi-values out of the box like Gris is looking for, so as I said--depends on what you're doing and what you want to do it with.

I think I've had it up the wazoo with my Linksys WRT54G. End of life, baby. The devices on my network are faster now than they were when I bought it.

I'm looking to continue on in the DD-WRT tradition. Which router manufacturer should I start my research with? Who's got a good reliability/price combo?

From a quick scan of the DD WRT site it doesn't seem that they support a lot of devices with more than 4 LAN ports. What's the general market look like? I mean has the basic featureset of a wireless router caught up to DD WRT? If I want to run internal DHCP and DNS, for starters, am I likely to be able to get that out of the box?

In old fashioned relational theory, (Codd & Date) the argument would have been that those compound fields should be alternate keys, not primary keys. But it does seem that relational theory has been eaten up by newer models. Even Codd admitted that we need 3D data, which lets in object orientation and so on.

You'll get DHCP out of the box, but I doubt you'll find DNS out of the box. Why do you need a router with more than 4 LAN Ports? You could just get a switch.

I have a Netgear WNR3500L (a gigabyte router with a USB port) which should be very DD-WRT friendly. I'm still using the Netgear firmware though as it ties into the OpenDNS parental controls. Netgear even has a website for the open source alternatives for their routers.

[link]