Im getting confused on this day fixing the database for having the consistent field name.
When i want to name the field to explain: the name of the one who locked, or hidden the post.
What's the field should i use?
locked_by_username , lock_by_username or lock_username
hidden_by_username , hide_by_username or hidden_username ?
Present tense or past tense? and should i use by inside the field name, does it a bad practice?
I see many database use post_username or poster_username to describe the username of the one who posted the post.
But with lock and hide verb, i can't see any the good way for describing it.
Sorry, i know this is a really stupid question, but English isn't my native language.
Whether your native language is Kiswahili or Klingon or English, what you want here are column names that describe current state. For example username_holding_lock means the column contains the name of a user holding a lock on the row.
Somebody using a tool to troubleshoot by doing SELECT * will then be able to guess what's up when the value TomSawyer appears on some row.
I think this is more opinion based but I generally would use camel case.
I personally would use:
HiddenByUsername
LockedByUsername
A good idea might be to look at some of the Microsoft sample DB's.
A example would be the AdventureWorksDB or you can look here
http://codeplex.com/SqlServerSamples
Related
How to generate MySQL Querys with LUIS and fetch data from the DB hosted in Azure?
Should generate a natural language query to an MySQL Query.
e.g.
How much beer was drunken on the oktoberfest 2018?
--> GET amountOfBeer FROM Oktoberfest WHERE Year ==2018;
Does anyone has an idea how to get this to work?
Already generated small Intents in LUIS e.g. GetAmountOfBeer
Dont know how to generate the MySQL Statements and how to get the data from the DB.
Thanks.
You should be able to achieve this, or something similar, using intents and entities. How successful this can be depends on how many and how diverse your queries need to be. First lets start with the phrase you mentioned: "How much beer was drunken on the oktoberfest 2018". You can easily (as you've done) add this as an utterance for an intent, GetAmountOfBeer. Though I'm a fan of intent names that you can read as "I want to GetAmountOfBeer", here you may want to name the intent amountOfBeer so you can use it in your query directly.
Next you need to set up you entities. For year (or datetime rather) that should be easy, as I believe there are some predefined entities for this. I think you need to use a datetime recognizer to parse out the right attribute (like year), but I haven't tried to do this before. Next, Oktoberfest seems to be a specific holiday or event in your DB, so you could create a list entity of all the events you have.
What you are left with is something like (pseudocode) GET topIntent FROM eventEntity WHERE Year ==datetime.Year, or something like that.
If your query set is more complex, you might have to have multiple GET statements, but you could put those in a switch statement by topIntent so that, no matter what the intent is, you can parse out the correct values. You also might want to build this into a dialog where you can check if the entities exist, and if not, you can prompt the user for the missing data.
I'm creating a small questionnaire, with below database design; following the schema from this thread made by Michael Durrant, with slight modification.
Now, for some questions, I must provide cities as options of answers; which already there in master_cities table.
Eg: Which city do you reside now?
Answer will be in dropdown format which derived from a master_city table.
I shouldn't copy the whole content of master_cities_table into option_choices table, should I???
Any ideas are greatly appreciated.
Edit: I'd like to clarify the question.
This question is totally unrelated with UI/UX, pure db design.
The goal I'm trying to achieve is to avoid data redundancies such as copying master table records into options_choices.
Since it's a survey system, all the choices of answers must be
database-driven, like A. Strongly agree, B. Neutral, C. Totally
disagree. Which could be reused to answer other questions, like
"Where were you born?" or "Which cities have you lived before?"
Master_cities table here is only one of the master tables (and the
biggest) that I need to refer to provide choices of answers.
Hope that clears the confusion.
Current approach:
I removed the referral_table field in options_choices table and put it
inside the options_group table instead,
set option_choice_id in answers table as NULL-able,
and save the master_cities primary key as text in answers_text field.
That seems to work.
But, there maybe a better approach out there, so you're welcome to share your insights, oh db experts!
Don't know. Usability would suggest that too long a drop down list won't be a good user experience.
Another approach would be to try type ahead, similar to what Google does when you start typing terms in the search text box, to look up city names. Once the user types a letter into the text box, you can narrow the query down and only present city names that match.
I have wondered this for many years and every time I did a search it was totally unrelated to what I am looking for as it thought I was searching for "how to comment out data". When you create a new DB table in phpmyadmin, there is a comments field there. What the heck is that for? :) I assumed it allowed you to leave notes on that field or something, but I tried to enter data in that field once and look around that table and didn't see anything. Please let me know what its purpose is. Thank you :)
Its simply just a comment so if you need to go back to that column and remember why/how you created it, you can reference it.
For Example: storeHeadID : int, comment: "This is the ID of the store's head office"
Once you added a comment in the comment field for a column, you should see a dotted underline under that column name in the table's structure view. If you mouse-over that underline you will see your comment as a tooltip. It is very handy to keep track of what the different values in the column mean eg. "status 0:disabled, 1:active, 2:suspended etc."
It's a comment field that describes the column. Although optional, some gui data browser applications format the comment field nicely at the top of the column. I think even good old PhpMyAdmin handles that if I recall correctly. Hope that clears it up for you.
Happy coding.
Your assumption was right, you can describe a column with plain text in any way you want – its purpose, its meaning, its side effects, for later, for others, for user comfort, for completion's sake.
If you're using phpMyAdmin though, take note that this feature was implemented no sooner than in version 2.6.4.
Release notes
Improvements
Display column comments while editing data
In older versions of phpMyAdmin that text (or even the field) doesn't show up at all, even though you can set a comment via inline coding.
I am trying to set up a few checklists, which users can save & go back to. I haven't set up user profiles yet.
How should I set up MySQL database? So far I have one database (e.g. lists_db), and am creating a new table for each separate list. Is this the right way to do it?
Also, what fields shall I have? ID presumably, and then what? How does MySQL read checkboxes?
Thanks in advance :-)
Are you storing the questions and answers or just the answers? If you just had one list, you could create a table for the questions (columns question_id, question_text) and a table for the answers (columns question_id, user_id, checked).
You could create a new table for every list, but this might be cumbersome. With two separate tables, it's possible to add a column to the questions (question_group_id) and store everything in a single column.
Regarding how MySQL reads checkboxes, databases generally don't store information specific to a UI component. In this case, the underlying data element is a boolean indicating whether it is checked or not - or in MySQL, a bit datatype.
I suspect you may be conflating persistence with user interface. MySQL has no notion of a 'check box'. Rather, a database is a representer of facts: It will remember the information you ask it to remember, but it makes no attempt at organizing that information in a way that's useful to a particular application.
As for remembering whether a box has been checked, you most likely want BOOLEAN (a synonym for TINYINT(1). You would represent an unchecked box with a value of zero, and a checked box with a non-zero value.
I have a MySQL table , each row representing a Person. For each person I would like to show a list of related links (when generating his page on my website), so I created a column called "RelatedLinks" which there I save raw HTML content such as:
Related Link 1 Related Link2
Then I just use PHP to echo $row["RelatedLinks"]; within the HTML itself.
The problem with this implementation is that I have little control over the links, for example in changing their order of appearance on the website, deleting/editing a specific link and so on.
The second idea I thought about was to create a column in the table for each related link, such as "RelatedLink1", "RelatedLink2" and then use PHP to echo $row["RelatedLink1"] . "<br />" . $row["RelatedLink2"].
Although I do have much more control with this implementation, I think I am creating a big overhead in the table.
What is an efficient way to achieve this functionality?
EDIT
Referring to Gabriel's answer, the question now is about complexity:
With the current implementation, once I select the person I have all the links in my hand - complexity of O(1). What will be the complexity of running a query to select all foreign keys of the current Person, as suggested by Gabriel (and Haim) below?
Thanks,
Joel
If you only want to store and display the links, and the edit actions are very few, the first option is the best one. In this case, you will have to save the new values on edit.
If you think you'll have more edit operations, you could try to create a second tabel, to contain id_pearson, link, text, order . And you can use this tabel to edit the links for a specific pearson.
Also, if you need the same link for two or more persons, it's preferable to use 3 tables.
persons table : id_person, name (and all other info)
links table : id_link, text, link
person_links : id_person, id_link, order
Using this setup, you can edit the links in one place, and all persons will have access to the same version.
LATER EDIT IN RESPONSE TO COMMENT
Okey, regarding complexity of operations, nothing could beat the first solution. But you must take in account several things regarding what you need:
how often do you expect to change the links ?
who is gone change the links (the admin of the site, or the end user) ?
how many cases of the same link to appear for different persons (using the first solution, you will have to edit all persons that contain that link )
To answer your question of complexity, the solutions proposed by me are O(n) if I'm not mistaking. Using foreign keys and proper indexing in MySql, you shouldn't have a problem with this.
Summary: if performance is very important to you and the links will be edited only by the admin, use the first solution. If not, I would use the third one.
Hope this helps,
Gabriel
You need a secondary table that contains a PersonID (foreign Key), RelatedLink(ID) and maybe an OrderID.
Something like
Table PersonRelatedLinks
PersonID
RelatedLink or RelatedLinkID
OrderID
SpecialFormat maybe