I wanted to see how far I could get today and I’m tapped out and have bills to pay. Things are a little screwed up now. If you go to the http site it redirects you to icwydt.com - so you have to go to:
And this will probably come down tomorrow or Tuesday because I have something else not working while this is the way it is. It’s repurposing some other stuff, but setting up a development environment for react/python/flask/mysql on windows, getting it to work, doing all the apache configuration, getting it to git, getting it to sorta work on linux, and dealing with ssl/tcl seems pretty good for one day. This might even just die on it’s own, I’m not sure I have the nohup working on it.
Someone from the Bay Area hitting me now. Probably Zuckerberg and he’s sad that he’s way behind in the Walrus game. Hey Zuck!, I’m not for sale! You heard me.
я не продаюсь!
In naming stuff in a database is it generally considered preferable to avoid using the same names for columns in different tables or not?
eg
game table has
game_id and title
category table has
category_id, game_id, title
would you name both the title of a category and the title of a game “title” or would you name them “c_title” and “g_title” or something like that even though you can tell from context?
Also, in general do you prefer to handle constraints from the backend programming side or in the database? Like, in the category table the combo (game_id, title) should be unique. Would you put that constraint in the db? I don’t see why not, except maybe you prefer handling errors on the program side?
What is the relationship between game_id between the two ? If it’s 1:1, eg they map to the same game id (which i’m kind of assuming is a key) it makes more sense to name it the same thing, IMO
I imagine you would prefer the opinion of someone who knows what they’re doing, but I would probably call the category field “category_name” or “category_label,” which I think are slightly more precise words to use anyways.
On the uniqueness point, I would have thought that game_id, category_id and category_name would all be unique in the first place?
The IDS are primary keys for the tables and must be unique. The name should be unique, but the question is whether it is better to enforce that as a constraint on the table or programmatically. An error will have to be dealt with in the program anyway.
I generally name things so that it is obvious from the name where it belongs, but that can get tiresome and I’m wondering what the standard practice is.
It seems like it would be desirable for your db to be able to promise that it would return a single category for a name lookup, which would require it to enforce uniqueness on the category names.
I think ‘title’ is the right column name (rather than ‘game_title’ for example). It doesn’t matter if different tables have the same type of property, it should be obvious what it means.
I even go so far as to give most tables an ‘id’ column and then when it’s referenced from a different table it’s [table]_id. So game has ‘id’ and ‘category_id’.
If you have a hard constraint I’d also put it in the database. Depending on the application it might or might not make sense to check there but I think it always makes sense to protect your data. Especially because you might not always be writing from the same place.
In the next week I am going to program a 2d game, think galaga type of game but with boats. Do any of you know any good software or resources out there for creating good sprites? Unfortunately, I am not very artistic. Thanks
React (Router) people - passing parameters around in props.location like they part of a URL query string. Is this cheating? Bypassing some benefit of React?
