<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Sean McAfee wrote:<br>
<blockquote cite="mid20050325225357.710D3BC77@mail.schwag.org"
type="cite">
<pre wrap="">What three locations are these? I see only two: the BUGS table and new
tables for storing one or more fields. If you're referring to the three
schemes I outlined, the first two are mutually exclusive.
</pre>
</blockquote>
The three locations are:<br>
<ol>
<li>the bugs table;</li>
<li>a single separate table;</li>
<li>field-specific tables.</li>
</ol>
All three can be used in a single Bugzilla installation simultaneously.<br>
<br>
<blockquote cite="mid20050325225357.710D3BC77@mail.schwag.org"
type="cite">
<pre wrap="">What is this good default? Why is it good?
</pre>
</blockquote>
The good default is probably to store custom fields in a single
separate table because most custom fields are short and sparse.<br>
<br>
<blockquote cite="mid20050325225357.710D3BC77@mail.schwag.org"
type="cite">
<pre wrap="">How general is this administrative UI going to be? I can think of plenty of
possible field-shuffling actions one might want to perform, such as:
* Move a field from BUGS to another pre-existing field table
* Move a field from BUGS to its own new table
* Move a field from a field table to BUGS
* Move a field from a field table to another field table
* Merge a field table into another, or into BUGS
Will the UI support all of these?
</pre>
</blockquote>
Maybe, if users demand them, but it will likely support (in order of
implementation):<br>
<ol>
<li>moving a field from the single separate table to a field-specific
table;</li>
<li>moving a field from a field-specific table to the single separate
table;</li>
<li>moving a field from the single separate table or a field-specific
table to the bugs table;</li>
<li>moving a field from the bugs table to the single separate table
or a field-specific table.</li>
</ol>
<br>
<blockquote cite="mid20050325225357.710D3BC77@mail.schwag.org"
type="cite">
<pre wrap="">In a large installation, any of these actions might require important tables
to be locked for the duration of the operation, locking users out for
possibly a lengthy period as the schema changes.</pre>
</blockquote>
Yes, but schema changes are rare.<br>
<br>
<blockquote cite="mid20050325225357.710D3BC77@mail.schwag.org"
type="cite">
<pre wrap="">Conceivably, a program
might resume after such an operation and find that its notion of the schema
is no longer current, probably leading to nasty errors. Is this acceptable?
</pre>
</blockquote>
What program? And how does this differ from FAD custom fields? FAC
doesn't modify the standard schema, and third-party applications that
rely on custom fields will break whether the schema being modified is
FAC or FAD.<br>
<br>
<blockquote cite="mid20050325225357.710D3BC77@mail.schwag.org"
type="cite">
<pre wrap="">Will the administrator have to be intimately familiar with the Bugzilla
database schema to be able to make field-storage decisions, or will the
interface help him to do so in language that's relatively easy to
understand?
</pre>
</blockquote>
The latter.<br>
<br>
<blockquote cite="mid20050325225357.710D3BC77@mail.schwag.org"
type="cite">
<pre wrap="">How exactly *does* one decide how to store fields? If there's a
straightforward algorithm for it, it's not obvious to me.
</pre>
</blockquote>
If it's short (in column width, not value length) and dense, put it
into the bugs table. If it's short and sparse, put it into the single
separate table. If it's long and dense, put it into a field-specific
table. If it's long and sparse, put it into a field-specific table.<br>
<br>
<blockquote cite="mid20050325225357.710D3BC77@mail.schwag.org"
type="cite">
<pre wrap="">If you agree with me that these are important issues, is the full power of
generality in this approach really worthwhile?
</pre>
</blockquote>
No, but neither is the generality available in FAD. What is worthwhile
in FAC is its alignment with the Bugzilla codebase and standard fields;
adherence to the ER modeling used in most database applications and for
which relational databases are optimized, and better security.<br>
<br>
-myk<br>
<br>
</body>
</html>