Indexes are used to quickly locate data without having to search every row in a database table every time a database table is accessed. An index is a copy of selected columns of data from a table, called a database key that can be searched very efficiently that also includes a low-level disk block address or direct link to the complete row of data it was copied from.
nice video. tomorrow is my exam on web designing, circuit, history of computer technology, programming and database. I didn't know anything about database management. the video really helped. thanks
Create index not give that much fast...in my table i use more trim(SUBSTRING_INDEX(SUBSTRING_INDEX(SUBSTRING_INDEX AS is it slow the execution time ? if this is the pblm give any suggesstion
I use many Flat Files, with fixed-length records, and "text" fields, working in tandem with Perl SDBM binary files of key/value pairs tied to Perl program hash tables. These key/value pairs offer persistent, instantaneous, random access to Flat File records. For random access, the file pointer is first set to a single record location byte offset, where the offset is the number of bytes to seek to from either TOP of file or END of file. Then the record is read into memory. Once in memory, the contents of the record can be changed/modified and written back out to the Flat File, overwriting the existing data stored in that record.
Thanks for the explanation. The only con I see is that to generate an index you first need to scan the whole thing. But I guess its pro as that you only have to scan once.
i think the index is incomplete, it should be a tuple (element, place) no? so the systeme knows where to locate it, like the word for example (word, page, line, column) so the reader will go directly to the word?
It needs to include the element in question and a pointer to the location, yes. The pointing or locating is normally done on the physical (i.e. disk block) level, so it is not exactly correct to think of the index as a tuple, but I can see where it would be useful to think of it as such. In any case, you are certainly correct that it does no good unless it provides a mechanism for going from element to its location in the underlying table.
What I've understood is that an index is used to find specific records of data quickly. The index is a separate, independent data structure that you can look through regarding a specific value, such as the company number in your example. The index structure for all the company numbers appears to be ordered. This way, someone can go through the values in order so they can quickly find the specific company number they are looking for. Once they've found the number, the index will point to the specific record in the database that it is referring to. The index structure is also nice because you can easily realize when you've exhausted your search for the company number you're looking for because if you stumble upon a different value, that means your search is over.
You can download my example PERL source code here (fully functional GUI application program) in PDF format. Click on the "Original File" link on that page to see the PDF file in a PDF viewer for download. I use Joint Database Technology as the Database (Flat File databases and SDBM databases working in tandem). The binary SDBM databases are used for indexing to the records in the Flat File. en.wikipedia.org/wiki/File:KJV_Bible_SDBM.pdf Also see the wikipedia page: en.wikipedia.org/wiki/Dbm for screen shots of this GUI application DB user-interface I guess this qualifies as a type of ISAM/NoSQL DB Access, and may be considered an Embedded Database?
