On Tue, Jun 17, 2014 at 5:15 PM, Albert Coder <eralbert9...@gmail.com> wrote: > I tried to implement the current database as such in the MediaWiki > extension that I have made but the current database has some > attributes which seem to be redundant and useless.
You can improve database schema. Remove redundancy, and propose with justification (as suggested earlier). > For eg. userID vs > desc_author and materialID vs table_materialID(in both the cases the > values are exactly the same for both attributes and I tried asking > about this in the mailing list and IRC before). So I have tried to > improve the database with some minor modifications. Good efforts, and everything is fine. > I have introduced > the categorization of both materials and properties which will help in > better searching and filtering. This is good addition. > You can have a look at the enhanced > database design below: > > http://202.164.53.122/~albertcoder/images/fdb.JPG > > Suggestions are welcome for any changes in this database design and I > will be carrying on with this database design henceforth. You are lagging behind. You need to show your code, your commit numbers. You are advised to us your real progress. Hope you must have gone through http://www.mediawiki.org/wiki/Manual:Database_access > As we are having a separate table for each trait we add, we might have many a > number of tables(might be more than a 100 in future) although this was > discussed before too. I was obliged to ask this as I have explored > other Materials Database resources too like matweb.com , matdat.com > etc. These have too many properties(near about 100). After referring > to Wikipedia I have made a spreadsheet of the properties so that we > can mark which properties are of our concern. > > Wikipedia> http://goo.gl/iyH8Am > > Matweb.com> http://goo.gl/2yUc0G Good for planning and reference. > The matweb has even over 100000 materials so in the near future we > might have these many properties and materials too. So what I wish to > re-confirm is that is this database design apt? It all depends on software your produced ;-) If it nice, then BRL-CAD community will enrich this database, and who know it may surpass above figures. > And regarding the naming of databases and tables, are there any > BRL-CAD conventions? Take hint from HACKING file. -- H.S.Rai ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
