Database Security

Posted by Glen on Aug. 25, 2010, 1:24 p.m.

Is a database controlled by .ini files a big risk? With websites of course. I'm just questioning the main advantages of going with mysql. I'm starting to need values saved and retrieved in my current website and I find .ini files easy to work with, but I'm wanting to learn mysql as well. But yea, for things like download counter, rating systems, and log in systems.

I've tried talking to people on website forums, but no one is ever active on those things and to be honest, I find more help from 64d with every problem I have whether it be game design or deciding what to eat. You guys are always a big help to me. I appreciate it. So if anyone can help me out here with a few new systems, let me know. Currently I use .ini files because that's what I was familiar with. I used .ini files in game maker all the time for stuff like this. But now I'm wondering if it's "that bad" of a thing to approach my website needs with the same strategy.

Comments

PY 14 years, 3 months ago

At the levels of data you're talking about, it's somewhat immaterial. Personally I'd just have a column for category, if every item can only be in one category.

Glen 14 years, 3 months ago

Every item can be in multiple categories. That's why I mentioned just breaking it down into different tables.

PY 14 years, 3 months ago

oh, I'd probably go items | categories | itemCategories, with the latter table just storing item and catergory IDs to link together. But I was never very good at databases, so I could be going about that the wrong way.

Glen 14 years, 3 months ago

My way is working. I'll just need about 15 tables to complete the system. I'm sorting 1,800 values. All being just id numbers. When I want to show everything in a category, I just open up the categories' table and read the id of every row inside it. That's kinda how I had my .ini system. Using the mysql database is making is much easier to do this though. XD

PY 14 years, 3 months ago

It's a shitload easier to query stuff and add new categories my way, though :P

sirxemic 14 years, 3 months ago

table categories:

ID | category_name

table items:

ID | item_name | category_id

Trust me.

PY 14 years, 3 months ago

How does that handle multiple categories, though? I suppose you could do a list of some kind, but isn't that then defeating the point?

KaBob799 14 years, 3 months ago

Duplicate entries.

item_1 cat_1

item_1 cat_2

This is how I handle friend lists on my sites =p When dealing with numbers alone, as long as you put an index on it then having a ton of entries doesn't really matter at all and is a lot easier to handle with code.

sirxemic 14 years, 3 months ago

Quote:
How does that handle multiple categories, though?
There is one table for all category names, and in the other you say which category it belongs to by linking to it in a field.

EDIT: Just realized I interpreted 'multiple categories' wrong.

Yeah, then what you proposed is better =P

firestormx 14 years, 3 months ago

Yeah, if I recall correctly, that's database normalization…Or something. Haven't even googled that term in 6 years, so I may be wrong.

Basically you have a table for your items, a table with only the names of your categories (or whatever info is needed for a category, such as a description as well or something), and a table that contains the item ID and the category ID, like Kabob said.