Ne, i was thinking, on ACDB there could be a category called wings since there is the one with ears now..? I think it's quite important to have that kind of thing.. it'll make some things easier..?

Wings? I'll leave up to tags.

I'll check out if I can add a Tag field to the search bar... so far we have the option to remove characters from search results by tags, but maybe the opposite can work too!

Like, you'd be able to use the normal search dialogs, then type in the tagged box "wings", and you'd only get matching characters that were tagged wings, or whatever tag you enter. The only issue for me here is how long the search takes. If it's under a second or 2, I'll do it. It it takes about a minutes or two.... that'd be a problem.

私は日本語を少し読むと書くをできます。あなたも？

If you have a "built-in" field for cat ears, I don't see why you can't have one for wings...

Haha, well... the thing is.... if I add a new standard search criteria, it would reduce my efficiency of bulk indexing characters by 16.6% ! So instead of indexing each character in 0.75 seconds, it would take me 0.87 seconds, and I just can't afford that. Making 6 decisions in a fraction of a second I can do, making 7... so not only would it decrease efficiency, but also increase chances for errors.

But I have good news! I figured out the SQL code to search within tagged characters, and the queries return results in 0.01 seconds. I'm retooling the search code at the moment. I think I'll add this to the Quick Search bar at the top. Might be done in the next few hours, or later today.... depending if I pull an all nighter or not. 3:40AM right now.


Edit: 4:50AM, I've tested the code enough...
Here's a winged character search: http://tinyurl.com/kv3tjk

[ Edited Jun 22, 2009 ]

私は日本語を少し読むと書くをできます。あなたも？

I don't see why adding one extra field should decrease indexing efficiency, but then again I don't know your database structure. You seem to be content with your current solution anyway.

Right.. I like the core criteria as they are. Eye Color, Hair Color, Hair Length, Age, Gender, Mimikko - which seems to apply to all characters more or less.

Wings would be a subset of Mimikko. I'd be surprised if more than 100 characters have wings. So, doing this through tags means less work for me, and has all the benefits of searching characters with wings.

The database structure for characters ( as of Jun 23, 2009 ) can be viewed here:
http://www.animecharactersdatabase.com/hosted/dbstruct.txt

私は日本語を少し読むと書くをできます。あなたも？

So how are you storing tags? In a separate table, I presume?

A single, properly indexed field wouldn't add any noticible overhead, and the query should run just as fast as any other. In fact, I'd bet it would be faster than whatever you're doing with the tags. Still, I'll reserve judgment until after I've seen your tag table structures.

Please note that I'm not so much arguing for "wings" criteria here as analyzing your database structure. Which, I've learned, you don't particularly like me doing, so if I'm being a nuisance you just let me know.

Kyareshi So how are you storing tags? In a separate table, I presume? A single, properly indexed field wouldn't add any noticible overhead, and the query should run just as fast as any other. In fact, I'd bet it would be faster than whatever you're doing with the tags. Still, I'll reserve judgment until after I've seen your tag table structures. Please note that I'm not so much arguing for "wings" criteria here as analyzing your database structure. Which, I've learned, you don't particularly like me doing, so if I'm being a nuisance you just let me know.

It's alright, I don't mind a good spirited informative discussion. It's a good way of learning. Only thing I don't like is unpremised "why" questions, which you avoided skillfully.

Tags are stored in two databases, tags and tagged.
`tags` contains an id, the tag in text, and the uid of the person who created the tag.
`tagged` acts like an assignment table, with an id referencing what was tagged, a flag value identifying the table of what was tagged, a tag id referencing the text value of the tag, and a uid identifying who tagged it.

I'd say this is the ultimate level of efficiency. No text is ever duplicated. And tags can be used for any database I wish.

Back to the "core criteria". Just to highlight what I hope you saw in the characters table definition, the core traits are all tiny ints stored in the characters table, such that only one table need be checked when doing a search.

私は日本語を少し読むと書くをできます。あなたも？

Rei Only thing I don't like is unpremised "why" questions, which you avoided skillfully.

Then you're going to hate me for the next question.

Rei Tags are stored in two databases, tags and tagged.

Why on earth are you using two separate databases?

Rei `tags` contains an id, the tag in text, and the uid of the person who created the tag. `tagged` acts like an assignment table, with an id referencing what was tagged, a flag value identifying the table of what was tagged, a tag id referencing the text value of the tag, and a uid identifying who tagged it.

That is a typical solid design for an "intermediate" table such as this. I don't understand, however, your referring to the table-identifying value as a "flag". Flags are on/off fields. Somehow, I don't think that's what you meant.

Rei I'd say this is the ultimate level of efficiency. No text is ever duplicated. And tags can be used for any database I wish.

In that case, I assume you have indices declared on all searchable fields. This is standard procedure for frequently used foreign keys (fields linking to other tables), though you probably couldn't declare the foreign key constraint itself since you are apparently linking between databases (this is more of a data integrity issue than an efficiency issue, of course).

Rei Back to the "core criteria". Just to highlight what I hope you saw in the characters table definition, the core traits are all tiny ints stored in the characters table, such that only one table need be checked when doing a search.

This is quite fair.

Because it is the best choice to achieve these two goals: "No text is ever duplicated. And tags can be used for any database."


In the table definition, it is a flag. The field is called `corp`, character or publisher. However, it is an unsigned tiny int, so if I wanted, I could choose additional values to reference additional databases.


Hai desu. However, I do not use foreign key constraint's, they get in my way. Given the fact I built everything, I can assure you no nodes are ever linked to non existent data. I write my own functions to check both sides exist before performing any assignment ( OK, most assignments. lol Either or, I can't say for sure. But I can still assure you! Maybe... ).

[ Edited Jun 24, 2009 ]

私は日本語を少し読むと書くをできます。あなたも？