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

Yeah, that I understand, but how many databases are you tagging here? It would seem for me as an outside observer that you would only need one database for the purposes of this site (excluding the one presumably used by the forum software, of course).

Rei 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.

The typical meaning of the term "flag" in computing is true/false, though I see that in some cases it is actually used for switches with multiple states. While I can't say that your use of the term here is outright wrong, I will warn you that it's somewhat confusing.

Rei 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... ).

You don't sound too confident. And that's because any good programmer knows that his own code is not perfect. it's always better to have integrity constraints on the database side, so that even if you make a mistake on the coding side, you will know that your data integrity is intact.

Kyareshi Yeah, that I understand, but how many databases are you tagging here? It would seem for me as an outside observer that you would only need one database for the purposes of this site (excluding the one presumably used by the forum software, of course). The typical meaning of the term "flag" in computing is true/false, though I see that in some cases it is actually used for switches with multiple states. While I can't say that your use of the term here is outright wrong, I will warn you that it's somewhat confusing.

Both those points sound like an issue of definitions. It's worth noting I define words to suit my needs, and that isn't always what everyone else uses them for.
[list]by database, i mean a table within a database
*by flag, i mean an identifier that creates a subgroup within a table. see i could have multiple databases, one for character tags, one for publisher tags, one for image tags, etc, or i could use a single table and just flag each tag as being an image,character,publisher tag. [/list]

Kyareshi You don't sound too confident. And that's because any good programmer knows that his own code is not perfect. it's always better to have integrity constraints on the database side, so that even if you make a mistake on the coding side, you will know that your data integrity is intact.

Partly because I had just recently one case where an uploaded character was assigned to a non existent series. But that was easily fixed with a couple of manual SQL queries to the related tables, and coding of a new function to verify the series ID exists before auto assigning. I think it's fun to handle the integrity constraints personally, rather than on the database side. I stand by my point, that keys get in the way. IMO, no query should ever fail.

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

Oh boy, Rei, now you've gone and opened a can of worms.

Rei Both those points sound like an issue of definitions. It's worth noting I define words to suit my needs, and that isn't always what everyone else uses them for.

What you're basically saying is that you confuse words and won't admit that you were wrong. I seriously urge you to stop doing that, otherwise no one is ever going to know what the heck you're talking about.

Rei by database, i mean a table within a database

Tables and databases are two completely different concepts and can under no circumstances be used interchangeably. A single database consists of many tables.

Rei by flag, i mean an identifier that creates a subgroup within a table. see i could have multiple databases, one for character tags, one for publisher tags, one for image tags, etc, or i could use a single table and just flag each tag as being an image,character,publisher tag.

If I replace "database" with "table" here, your sentence begins to make sense. So you're using one field to specify which table the tag is referring to.

Rei Partly because I had just recently one case where an uploaded character was assigned to a non existent series. But that was easily fixed with a couple of manual SQL queries to the related tables, and coding of a new function to verify the series ID exists before auto assigning. I think it's fun to handle the integrity constraints personally, rather than on the database side.

You should be doing both. Checking for integrity on the coding side is definitely recommended, but a good database has its own constraints that act as a failsafe.

Rei I stand by my point, that keys get in the way.

If key constraints are getting in your way, then I think it's time to reassess your approach, because you're obviously doing something wrong.

Rei IMO, no query should ever fail.

So you're saying that you want bad data to be allowed in your database? I'm sorry, but I just cannot condone this. Bluntly put, it's a terrible policy.

we have a pride issue here I think, Rei isn't open to new suggestions is what I see here. With what little training I've had in database design what Kyareshi has conveyed makes a world of sense.

Suggestion to Rei: Think about the ideas that are being conveyed here, think about what would happen if the ideas Kyareshi is presenting were implemented and the outcomes that would be achieved. Personally, I see a big boost in productivity, time saved in maintaining data integrity, and a more organized/easy to understand database for you and others. With just putting in foreign key constraints to your tables you save yourself hours of tracking down bad entries, fixing those, and writing code to help with that. With the time saved you could invest that time in other, more interesting projects. Just run the ideas through your head, consider the ups/downs of the idea, maybe figure out some technical details so you can get an idea of what will have to happen.

Doesn't look like there's much left for me to comment on. :-P

I promise you both I have read everything, and I will reflect upon it.


I don't see it that way. The concept of table to me is a place I eat supper at. So I use database whenever I'm talking about a table. The times I talk about database in the way you see the word are very rare. Database = single table within a database.

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

^you have been over the idea of a table in terms of a database, right? I'd imagine if you're working in SQL you must've recieved the basics in some form or another. With the database term, think of a table as a 2d object, a file folder. A database is a 3d object, more like a file cabinet. A database is what tables are put in, just like a file folder is put into a cabinet.

brobb355 ^you have been over the idea of a table in terms of a database, right? I'd imagine if you're working in SQL you must've recieved the basics in some form or another. With the database term, think of a table as a 2d object, a file folder. A database is a 3d object, more like a file cabinet. A database is what tables are put in, just like a file folder is put into a cabinet.

Basics? What basics? You're forgetting I'm a CS drop out. :-P Using your terms, a "database" to me is just a label - nothing more than an identifier for a series of related tables. MySQL treats the "database" as a directory where it stores table files. So at that level, you're explanation is entirely correct. You know, the actually "database" of Anime Characters Database is called char1. I wrote the definition for it in April 2007 (while i was still a kid reading blog posts on how other kids made databases). I haven't looked at, touched, or modified that "database" since it was created. Anyways, anytime I say database, I'm probably talking about a "table".

*goes back to writing php code*

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

Rei Basics? What basics? You're forgetting I'm a CS drop out. :-P

Being a "drop out" is no excuse for closing your mind to new concepts. I know you're an intellegent person, which is exactly why it irks me that you refuse to call a shoe a shoe and a glove a glove.

Rei The concept of table to me is a place I eat supper at.

Ever heard of homonyms, Rei?

Rei So I use database whenever I'm talking about a table. The times I talk about database in the way you see the word are very rare. Database = single table within a database.

You're doing it wrong. Anyone with even a basic knowledge of databases could tell you this. A database is completely distinct from a table, and by its actual definition is far more than a file folder. it's more than a collection of tables. Every database has its own tables, triggers, indices, store procedures and views, among other things. The fact that you are unwilling to accept this standard terminology is making it very difficult for other people to advise you.

Rei MySQL treats the "database" as a directory where it stores table files. So at that level, you're explanation is entirely correct.

For your information, not every database engine out there uses a directory structure like this. See my above response for a little more information on what a database entails.

Guess I wont be able to convince you guys to see it my way, huh. Oh well.

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

^well, "your way" goes against what we learned as the basic definition of a database.

May I suggest a quick read for you, Rei? "Database Design in Plain English" by Joe Herzog is an easy to read book and it'll explain a lot of concepts of databases in a way that a 12-year old can understand. This was one of my textbooks needed for the SQL class that I took over the spring.

[ Edited Jun 26, 2009 ]