Moshe Feiglin and Relational Database Theory

 

bs"d

 

 

Politics is not my thing but I can't understand why the most obvious merger is not being considered. Why don't the parties that have a common belief system and have consistently shown by their actions that  Eretz Yisroel is our Biblical Right,  use that as a common denominator to unite? 

 

Please visit http://shemittahrediscovered.blogspot.com/2006/09/manhigut-yehudit-broader-coalition.html

 

My  guess is that it has to do with the concern to be the uncontested leader.  Each party is afraid that if there is a merger with like ideology  then there is a possibility with a merger that  they will not come out on top and be excluded from the picture. 

 

My background is in computer database. I will use computer relational database theory as a Mashal to this discussion.  Please read through this until the end, even if it may be cumbersome.  Another example of relational theory is the INTERNET itself where each post and each individual post have equal access. 

 

Many years ago in the 1970's the concept of computer databases was in its infancy.  Previously every computer was stand alone with it's own application.  Each computer had a tape drive or cards and using Cobol or a similar programming language, files were defined and data was stored in certain locations where the particular programmer defined them to be.  As the level of sophistication grew,  the programs required shared date that was embedded in other programs.  As the application grew the entire system became unmanageable.  Each program defined their own files and each program reinvented the wheel using the same data in a different format according to the whim of the programmer.One program that needed data that was stored in a different application had to figure out how the data was stored and how to access it or redo similar aspects of the other application. This led to much waste, duplication, data integrity was compromised, unnecessary reprogramming and much error.  The programs were unable to grow as the application grew in scope. So the concept of databases grew and from there was developed a Database Definition Language and Database programming language.  Data no longer were stored in files that were part and parcel of a particular program but rather it was now in a place a Database, that was defined by a database definition language and accessed with a database language and was shared by many programs and many user applications.  At least now there would be less duplication of data, and the integrity can be better monitored.  Data was retrievable by many different programs.  This was a vast improvement.  The data in the database could be defined in a hierarchical manner or non hierarchical..  

 

Let's take a typical business application of invoices and present it in a hierarchical manner.  The master invoice file would have general invoice information.  Information on the Master Invoice would include the client, the invoice number, the date of the invoice and the total amount on the invoice.  Then there would be an embedded details file that would contain the details of the invoice.  Each detail would be another record on the details file that was embedded in the master invoice file.That worked fine if the view of the data was to produce invoices.  However when the inventory person in the purchasing dept.  needed information regarding parts, using the hierarchical method, described above, he/she was forced to access the invoices first and then get to the information that was embedded in the details to find out which parts were sold.  Such access was cumbersome.  The purchasing dept. have no real interest in the invoices themselves and in fact should not have any access to the invoice data. Their only concern is when  inventory for a particular part becomes low and requires reordering. As a programmer that became mired in trying to access data that was embedded I began to research relational Database model theory developed by E.F. Codd. 

 

The bottom line in relational database theory is that hierarchy can be simulated but no data is totally subservient to the master or embedded. The hierarchy is simulated by keys that connect all the masters with the details.  In reality it is as easy to access the details as it is the master. You can access the details directly or through the master.  In a relational database we can easily query which PARTS were used by a particular CLIENT, which PARTS were used in an INVOICE, which PARTS need to be reordered.  There is direct access to each piece of data via all the unique keys.  So if I wanted to store the data most efficiently I would have the following database files.  PARTS, CLIENT,INVOICEMASTER, INVOICEDETAIL., VENDORS, PURCHASE-ORDERS, PURCHASE- ORDER-DETAILS etc..  Each record in a database file must have it's own unique key.  So every Client record has a unique CLIENT ID .  Every PART has an PART ID.  Every INVOICE has an INVOICE ID and every detail on an invoice as it's own INVOICE_DETAIL ID.  etc,

 

So what is the Nimshal?  In reality we are all children under G-d.  Each one of us have a unique and DIRECT connection to G-d.   Yet we are also  family members with strong roots. We each have our own mission and talents and abilities that are necessary for a united whole and we draw our strength from the roots of our tree.  No individual can be negated because they don't belong to a specific hierarchy. We are equal under G-d in the sense that we each have a Tselem ELokim.  Our job is to bring out the essence of our individuality. 

 

As Jews we are working for a common goal. The goal is to serve G-d and keep the Torah.  That is the essence of Manhigut Yehudit.  As in a Database application each user has their own unique ID and  individual perspective. We can  be identified as So and So the daughter of So and So or alternatively by our social security number. We each carry our own individual view or perspective.  Each view is a legitimate view. 

 

 The Accounting Department has interest in parts insofar that they are a details on an invoice.  The Purchasing dept has an interest in parts insofar that they need to reorder them in order to keep inventory stocked.  The CEO of the company mav have interests in parts that don't break down and ruin his companies reputation. 

 

A typical Employee Database application will relate to the CEO as simply an Employee with a unique Employee ID or alternatively as a special employee with unique benefits.  In many aspects the CEO is simply no different than a regular employee yet is other ways he is the leader and has a different perspective and focus.

 

True being the winner and the leader is important. But a hierarchical model alone will not allow for growth or bringing out the individuality of each detail. That requires the Relational Model. The most effective leader will recognize and utilize each and every other leader'individual to promote Service of G-d and Torah.  My question is why aren't we uniting in our common goal. 

 

 

If you wish to visit my blog click on:
Shemittah Rediscovered

Please subscribe.

 

Thanks.