<div dir="ltr"><div>Create a procedure in your code base operations for the definition of customer specific data model classes that work through some kind of pluggability to operate the application in an instance mode that has those models. Your operations will also do the creation of tables as relevant in appropriate databases. Keeping control if this is somewhat tricky, is really best done with LOTS of automation so that there aren't any manual sql processes to process if at all possible. My advice is to put as much effort as necessary into the operational development in order to enable the automatic management of the back end storage and the classes for the application instances.</div><div><br></div><div>But to discuss the issue in general in aspect to horiz/vert table design (which is the usual customer-attribute problem, you probably didn't know the term):</div><div><br></div><a href="http://stackoverflow.com/questions/9256830/horizontal-vs-vertical-table-design-sql">http://stackoverflow.com/questions/9256830/horizontal-vs-vertical-table-design-sql</a><br><div><br></div><div>which references</div><div><br></div><div><a href="https://www.simple-talk.com/sql/database-administration/five-simple--database-design-errors-you-should-avoid/">https://www.simple-talk.com/sql/database-administration/five-simple--database-design-errors-you-should-avoid/</a><br></div><div><br></div><div>Which is all information you probably need to know to make an effective data model, read more books and stuff on it.</div><div><br></div><div>As a corrolary to my first paragraph, I want to say that the data model of an application is defined by the application itself. The data model of the indexing back end storage whose purpose is the retrieval of information in an adequately performant manner for the operation of the system is derivative and often closely coupled to the application. The less that you have to maintain the backend store manually in relation to the application model, the more maintainable your system will be. The usual tangle of database schemata evolution against the application evolution through its versions is for the most part avoided. </div><div><br></div><div>So to be precise, it depends on the use cases of using those attributes how you should render them in the database/dbix class definitions - the simple sideways table isn't performant, the operationally heavy new-tables-and-columns-for is somewhat perilous and increases ops load. But you got to do what you go to do given the constraints of the system and environment, right?</div><div><br></div><div>:D</div><div><br></div><div>David</div><div><br></div><div><br></div><img src="http://t.sidekickopen19.com/e1t/o/5/f18dQhb0S7ks8dDMPbW2n0x6l2B9gXrN7sKj6v4f8d6W2BFKF27gbCdzW4WYsVR3LvrVvW3tgpv81k1H6H0?si=4942347330912256&pi=268bcd8b-994b-47eb-f7df-64b76bcfd6cf" style="display:none!important" height="1" width="1"></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 27, 2015 at 5:33 AM, Alex Becker <span dir="ltr"><<a href="mailto:asb.cpan@gmail.com" target="_blank">asb.cpan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Dear all!<br><br></div>Whenever I start setting up a somewhat larger database, I come across the question: how to design customer-specific attributes?<br></div>I can't imagine that this question was not elaborated extensively in the Internet, but I did not manage to find a good article about it. Maybe it's something trivial.<br><br></div><div>Example:<br></div></div>Assume a generic web shop. You have a table of products. These products to have a set of pre-defined attributes like price, VAT, weight etc.<br><br></div><div>Some time later, new attributes will be added. Simple new, single-value attributes, as well as multi-value-attributes.<br></div><div>Like colors (can be either blue or yellow) or topics (1 or more of: gardening, cars, programming, ...).<br><br></div><div>Do you know a comprehensive guide how to do it best? In the ideal case, by using DBIx::Class :)<br><br></div><div>In the past, I used hand-make code to alter tables (add or remove columns, while keeping the default columns), and the normalization approach with single values attributes.<br><br></div><div>Best regards,<br></div><div>Alex<br></div></div>
<br>_______________________________________________<br>
List: <a href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class" rel="noreferrer" target="_blank">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class</a><br>
IRC: <a href="http://irc.perl.org#dbix-class" rel="noreferrer" target="_blank">irc.perl.org#dbix-class</a><br>
SVN: <a href="http://dev.catalyst.perl.org/repos/bast/DBIx-Class/" rel="noreferrer" target="_blank">http://dev.catalyst.perl.org/repos/bast/DBIx-Class/</a><br>
Searchable Archive: <a href="http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk" rel="noreferrer" target="_blank">http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">David Ihnen<br>Voice contact (562) 743-1807</div>
</div>