Indexing HTML Attributes and Unique Indexes

guest271314 guest271314 at gmail.com
Thu May 23 14:23:09 UTC 2019


If the HTML elements have a unique ```id``` set there is not search to
perform (```document.getElementById("id")```), correct?

Form fields can be created, set and changed using `FormData` objects
without using HTML elements at all.

Still not gathering what is meant by unique indexes.

On Thu, May 23, 2019 at 2:05 PM Randy Buchholz <work at randybuchholz.com>
wrote:

> Full Table Scans and Unique indexes are database concepts (that's the DBA
> reference). When a database searches for a record based on a column value,
> it might look at every record in the table to find the matches - scan the
> entire (full) table, in the order the records were inserted or stored. To
> speed this up, we can create indexes on table columns or column groups.
> These are like ordered maps or hash tables. To find a record, more
> efficient searches can be done against the indexes to find the records.
> Indexes can also act as constraints. A "Unique Index" is a constraint that
> checks a table to see if a value exists before inserting it in the table
> and adding it to the index. Indexing has a trade-off. It slows inserting,
> but improves searching. While understanding that databases and browsers are
> worlds apart, a foundational part of database engines is searching, just
> like it is in DOM manipulation. Indexing can provide orders of magnitude
> performance improvements when reading/searchin
>  g in databases. It seemed worth seeing if the concept translated across
> technologies.
>
> Without any optimizations, an attribute search on a document would look at
> each node, and then at each attribute of the node to find a match - Full
> Table Scan. This makes searches very slow. At an absurd extreme, we could
> index everything, making startup very slow and eating memory, but making
> some searches very fast.  The balanced approach is to implement "indexing"
> ourselves (using any of the mentioned approaches) to get the best level.
>
> About the code/HTML, it is dynamic and real-time. It is loaded over
> WebSockets, and the elements are talking to the backend in real-time over
> the sockets. I'm using an original (Trygve Reenskaug) MVC approach.
> Essentially, each Web Component is an MVC component, with the HTML/elements
> and code accessed only through the controller. I am looking at the incoming
> code for cases where several searches ae being performed on the same
> attribute (or element). I give these a generated `id`,  create indexes on
> them, and expose them as properties on the controller. The underlying
> framework uses a set of common attributes that are searched on a lot, but
> only for a small set of elements. These are also indexed. So at the cost of
> slower startup (offset to some degree by doing some of this in a Web Worker
> and/or server-side), I can read and write "Form Fields" quickly.
>
> Many language features are implemented to wrap or optimize common or
> repetitive use cases, or to move code to a more efficient part of the
> architecture. Indexing can do both. Without doing things server-side or in
> Workers, the indexing consumes UI cycles. Adding an indexing "hint" could
> allow all or part of this code to be moved back into the "system" or C++
> layer. (e.g., into `querySelect` internals supported by low-level map
> stores) Or to parsing (like I'm doing), taking some of the repetitive work
> off the UI and developers hands.
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190523/02a1aa39/attachment.html>


More information about the es-discuss mailing list