<!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">
Well, perhaps I can add a bit of practical experience to this, <br>
we had a similar discussion about a quite similar problem at<br>
our company some years ago.<br>
Probably it can help a bit to understand how others dealt<br>
with that, probably it adds just more crap to the mailinglist<br>
archive, but I think it's not on me to decide.<br>
<br>
We needed<br>
- a frontend for parameter setting<br>
- a backend for parameter retrieval and processing<br>
both for<br>
- an unknown number of users for which we had to store data<br>
- a (at that time) yet to determine number of parameter fields<br>
(we guessed to end up with ~25 fields at the end of project)<br>
<br>
Several discussions were needed and many of them starved<br>
just because we couldn't agree on one of these designs:<br>
- one table, each column representing one field value (FAC)<br>
- two tables, one representing the field name and id, the other <br>
one holding the field id, user id and its value (FAD)<br>
<br>
Some people finally decided to implement FAD just to try it<br>
and because adding more fields without having to change the<br>
DB/table design. When it was done it was accepted because<br>
having SOMETHING USABLE was better for our PMs than<br>
just TALKING about something.<br>
<br>
Near the end of the project we ended up with:<br>
- ~7000 users<br>
- ~150 fields, all of them used somewhere but rarely more than<br>
~40 fields actually containing something<br>
<br>
What happened? When users got aware that adding more fields<br>
could be done within seconds, they took advantage of it and used<br>
it heavilly.<br>
<br>
If we had used FAC we would have had a large table where only<br>
about 25% of fields actually contained something other than NULL.<br>
<br>
Max Kanat-Alexander wrote:
<blockquote cite="mid1106866185.12303.14.camel@localhost.localdomain"
type="cite">
<meta http-equiv="Context-Type"
content="text/html; charset=iso-8859-1">
<title>Re: Custom fields schema</title>
<p> On Thu, 2005-01-27 at 06:03 -0800, Myk Melez wrote: <br>
> In my experience it's just as dangerous to overgenericize because <br>
> someone might need some capability you don't know about yet. </p>
<p> Yeah, that's true.</p>
</blockquote>
Generally I agree, but in our case I'm thankful to that devs that did<br>
it nevertheless. We would have had a hard time otherwise.<br>
<br>
<blockquote cite="mid1106866185.12303.14.camel@localhost.localdomain"
type="cite">
<p> </p>
<p>> How does FAC make it harder to use placeholders? </p>
<p> FAC looks like this: </p>
<p> SELECT $column1, $column2, $column3, etc. <br>
FROM $table1 $possibleJoin1 $table2 $possibleJoin2 <br>
WHERE <criteria> </p>
<p> FAD looks like this: </p>
<p> SELECT field_name, field_id, field_data, bug_id <br>
FROM field_table <some_standard_joins> <br>
WHERE field_name = $fieldname </p>
<p> Only $fieldname can be a placeholder. You can't use
placeholders for <br>
column or table names. </p>
</blockquote>
I personally doubt that constructing a new SELECT statement in .pl,
having<br>
the DB to reparse, cache and execute it each time I need a field can
have a<br>
better performance than using a statement which looks the same all the
time<br>
for the DB thus avoiding reparsing, caching and all that other stuff
the DB has<br>
to do before actually retrieving data. <br>
But this is just my own opinion and probably can be proven to be wrong
easily.<br>
<br>
<br>
Overall, I hope this time the discussion, regardless how long it lasts
and which<br>
solution hopefully will be chosen, can be followed by a phase of
development<br>
so that Bugzilla finally can add a line<br>
- comfortable custom fields support<br>
to its feature list.<br>
<br>
Just don't let you pull into flames and perhaps try to evaluate the
pros and cons<br>
of every suggested design.<br>
<br>
<br>
Just my 5 ct.,<br>
Andreas<br>
</body>
</html>