Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
So what I am looking to do is have a survey whose answers are populated into an SQL database. One problem I am not sure how to avoid is allowing duplicates into the database.
For example, I want the user to tell us which organization they are representing.
Say one user enters "big brothers and big sisters" and another, from the same organization enters "Big Brothers & Big Sisters". I have a separate Organization table these answers would be populated into. How would I prevent this from creating two separate rows? There are several instances of fill in the blank questions that I foresee this problem occurring with.
You might try utilizing the Levenshtein algorithm ( https://en.wikibooks.org/wiki/Algorithm_Implementation/Strings/Levenshtein_distance ) and some languages (such as PHP) will have methods to utilize this built in. In addition, you'll probably have to build permutations of the input string by using common substitutions (& / and) and try validating the permutations against the database to make sure that it doesn't already exist.
For what it's worth, it might also be a good UI decision to present the user with similar options to make sure that they really did or didn't mean to type in what they did.
Sorry if it's not much help; not sure what your total requirements are. Hope this helps!
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have a data set of searches made on a website. I have to find top searches from that data set. The problem is, i cannot think of a way to do it. The search terms are long sentences. How could i find what are users interested in? It seems to be a problem of counting and i am using php. Any suggestion would be appreciated.
You can create a table in database, which will contain columns search_phrase and counter. Each time when user will search same phrase, you'll just increase counter instead of creating new row.
You can also create a script which will take all records from this table, and find similar phrases.
You can make counter corresponding to each phrase. Suppose You have a queries in long sentence format , divide your sentence into smaller parts and identify the most meaningful word and avoid the conjuctions and other verbs. Particularly focus on Nouns. For an eg, Query is : How to Make account on stackoverflow? Possible Solutions[words] : account, stackoverflow,make. Possibly in this way you can solve it.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Skip that if you value your time.
I am making a website that has a special "control panel" for a few (less than 20) people. It is a calendar where you can see which days aren't occupied yet and book "events" to them if it's needed. Panel uses php and mysql database to hold usernames, events etc. It is pretty much finished, but i noticed that i need to check if exact same data isn't stored in database already (it wouldn't cause problems, but it would be better to avoid redundancy).
First solution i came up with is just add a query (checking if there is an appointment in the time) to every added row (they are added in a loop) and do the INSERT only if checking query returned 0 rows.
You can really ignore anything higher than that, i added explanation only to clarify situation more.
My question is: Is it really bad for the server if there are many small queries run in a loop, or that doesn't really matter because queries are not that hard for a server? Maybe it really matters and i should for example run one, bigger query and save it into an array or something?
It probably doesn't matter but i am using object oriented setup from there
I am asking mostly to expand my knowledge, because this utility will be used only by one person anyways, so server will keep up even if it is not really efficient.
This is too long for a comment.
Is it a really bad idea? Depends on your definition of bad. In general, multiple such queries are more expensive. And multiple queries introduce more opportunities for race conditions. Doesn't sound like a "good" idea to me.
More importantly, though, is checking for duplicates in the application. You have a database and can use the database to prevent duplicates. This is called a "unique" constraint or a unique index (the former is implemented using the latter). Your question doesn't have enough information to make a concrete suggestion, but that sounds like what you really need.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
For example i have a field user-id in my mysql table users which identifies a user uniquely. If someone requests for example the friends list of a user i return a json array witch includes the user-id of each friend and additional data like name.
So my question is if it is an good idea to send these user-ids directly to the client. Is this insecure? Are there ways to hide the id?
Regards
It depends if leaking the ID information from your application is a serious issue or not. If you're in a highly competitive business where knowing the number of users on your system is valuable information, or where you're worried someone might step through them sequentially to download your database systematically, scrambling them does help.
Using a cryptographically random identifier or a UUID are two of the more common ways to solve this problem. A truly random identifier offers more security but will take more care to construct as there's many ways to get this wrong.
It's worth noting that sites like Stack Overflow leak user IDs because there's no value in hiding them. For example, your profile link has the user ID in it: 2441032.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
You find a lot of info on this online. But not what the exact work around of the use of Algorithm is in MySQL. The real basics, if you will..
What a query is, is obvious, of course. What Algorithm does, remains unclear.
Main reason for this question is: to improve profiling & matching records to known users. (In this case: to match docs in a database to users that need them)
Some examples of the usage of it are highly appreciated!
Algorithm is a keyword used with create view in MySQL. The documentation does a pretty good job of explaining it.
The short answer is that MySQL supports two methods of handling views: either "merging" the view definition in the calling code or creating a temporary table. The first is called MERGE and the second TEMPTABLE. In general, MERGE is faster, but most views are TEMPTABLE because of the restrictions on `MERGE.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I would like to set up an online store and a point of sale application for a food coop.
My preference is php/mysql, but I can't find any projects which accomplish both these requirements. I was wondering if it would be possible to use separate store and pos apps and get them using the same product database.
The questions I have about this are:
is it a bad idea?
Should one of the apps be modified to use the same tables as the other or should there be a database replication process which maps the fields together (is this a common thing?)
is it a bad idea?
The greatest danger might be that if someone successfully attacks your online store, then the pos systems might get affected as well. E.g. from a DOS attack. That wouldn't keep me from taking this route, though.
Should one of the apps be modified to use the same tables as the other or should there be a database replication process which maps the fields together (is this a common thing?)
If you can get at least one of the two systems to use the products data in read only mode, then I'd set up a number of views to translate between the different schemata without physically duplicating any data.