I am trying to speed up query processing in a database using an index.
CREATE INDEX PASSENGER_INDEX ON Passengers USING hash (name);
I need to use not only the first name but also the last name and patronymic, if possible. How can I do this?
Related
I have these two tables (products and brands table) and I need to create a fulltext index to support the search function for my website. I want an index that contains the brand name and product name of a product. And for this case, the columns come from different tables.
What I know for now is creating fulltext indexes from a single or multiple columns coming from just one table.
This is the preview of the database i am currently working on:
Database Preview Here
MySQL doesn't support any type of index covering multiple tables.
All columns of an index must come from a single table.
If you need to create a search engine over a multi-table dataset, you might consider exporting the result of a JOIN query to a fulltext search engine like Sphinx Search or Solr (which is the software inside ElasticSearch).
You might like my presentation Full Text Search Throwdown.
Perhaps you need to do the following...
Gather all the columns you are searching on into a single table. (Either move them to this new table or make copies.) This table would also have an id to link back to the main table.
Then focus on optimizing the search activity using that table.
Note that in copying columns into the table, you could do some cleansing (removal of kruft that interferes with searching, such as html tags, alternate spellings, etc).
Looking at your schema, I almost think this is a case where normalization should not have been done.
I have two question regarding N1QL query in Couchbase.
1: Let suppose I have user table where userid is document key and then i
fire a query like this
select * from mybucket use keys["1234"];
2: Let suppose userid is not a document key and then i create a secondary index on userid
select * from mybucket where userid=1234;
So my question is, which query would perform faster ?
Second question is,
Let suppose I have user table where userid is document key
select * from mybucket where meta().id="1234";
This query does not run and give me "No index available on keyspace".
It is a document key, it should run like "use keys". I tried to create a secondary index on userid but it says index can not be created since this field is not the part of document(obviously, it is a document key)
The first query will run fastest. Naming the specific key directly in a USE KEYS clause lets Couchbase retrieve the record directly in a single request. The second approach, using an index, will be slightly slower, because the system will first have to make a request to the index to get the document id, and then retrieve the record itself. The second approach will still be very very fast, but not quite as fast as the first one.
Yeah, depending on what version you are using, we may not be fully optimizing that third case. Use USE KEYS if you can.
I'm using MySQL Workbench to create a user table. I would like to make name and surname unique. On their own, name or surname are not unique as long as both are not duplicated simultaneously by a separate record.
Can I do this using MySQL Workbench or do I have to execute a a SQL statement manually? If so, what is the syntax?
So, there can be many name=John and surname=Doe but only 1 John Doe
In the tabs underneath the table design window, you'll see "Indexes". Click that tab, create a new unique index, tick the boxes for the columns you want to include in the unique index.
(The view you're looking at in your question is the "Columns" view, which lets you change details of individual columns, each of which can include a "unique" property, but for multi-column uniqueness you need to create an index.)
I am very new to database concepts and currently learning how to design a database. I have a table with below columns...
this is in mysql:
1. Names - text - unique but might change in future
2. Result - varchar - not unique
3. issues_id - int - not unique
4. comments - text - not unique
5. level - varchar - not unique
6. functionality - varchar - not unique
I cannot choose any of the above columns as primary keys as they might change in future. So i created a Auto-Increment id as names_id. I also have a GUI( a JTable) that shows this table and user updates Result,issues_id and comments based on the Names.Names here is a big text column. I cannot display names_id in the GUI as it does not make any sense in the GUI. Now when the user updates the database after giving inputs for column2,3,4 in the GUI i used the below query to update the database, i couldnt use names_id in where clause as the Jtable's row_id does not match with the names_id because not all the rows are loaded onto JTable.
update <tablename> set Result=<value>,issues_id=<value>,comments=<value>
where Names=<value>;
I could get the database updated but i want to know if its ok to update the database without even using the PK. how efficient is this? what purpose does the surrogate key serve here?
It is perfectly acceptable to update the database using a where condition that doesn't reference the primary key.
You may want to learn about indexes and constraints, though. You query could end up updating more than one row, if multiple rows have the same name. If you want to ensure that they are unique, then you can create a unique constraint on the column.
A primary key always creates an index on that column. This index makes access fast. If there is no index on name, then the update will need to scan the entire table to look at all names. You can make this faster by building an index on the field.
I've got the following situation: I want to store data, which represents, if a user is following another user. Another table, which I cannot touch, stores the users, where the username is the primary key (unfortunatly no id...).
The fact is, if one user follows another one, it doesn't mean, that the other one is following the first one.
Right now, I designed the table with two varchar's (128) and a UNIQUE INDEX on these two varchar's which represent the usernames.
The problem is, that I need to parse some old-styled system now, and I finished like 15% and I've got 550k entries on this table already.
The index is bigger then 16MB, and the data just 14MB.
What could I do, to save this data in a better way? As said, I cannot use id's instead of the usernames, because the user-table uses the username as primary key.
As you have noticed, creating a seperate index on all columns essentially forces MySQL to duplicate all data in the index.
Instead of creating a seperate unique index, you can create a primary key consisting of both of your fields. MySQL uses the primary key as a clustered index making sure your uniqueness constraint is still satisfied without increasing the size of your database.
You might consider building your own index table that contains ID > username.
You could then use the ID's to map the followers.
This will cause for some extra overhead if you want to retrieve all the data.