IcsTools.it

Sorry, this entry is only available in Italiano.

Sorry, this entry is only available in Italiano.

Sorry, this entry is only available in Italiano.

Sorry, this entry is only available in Italiano.

Sorry, this entry is only available in Italiano.

Sorry, this entry is only available in Italiano.

The U.S. Defense Department said in a voluminous document (released as open source) the reasons why the Army should use free software: the document is on Scribd.com .

Some passages are very significant, in particular:
DoD must have software that is easily adaptable to changing mission needs and can be evolved rapidly and delivered quickly at lower costs to meet mission requirements in a timely manner.

And also:
…a monopoly on the knowledge of a military software system and control of the software source code. This is optimal only for the monopoly contractor, but creates inefficiencies and ineffectiveness for the government, reduction of opportunities for the industrial base, severely limits competition for new software upgrades, depletes resources that can be used to better effect and wastes taxpayer-provided funds

What can I say? How true!

And, lastly, a summary of the advantages of the open source:

• Increased Agility/Flexibility
• Faster delivery
• Increased Innovation
• Reduced Risk
• Information Assurance & Security
• Lower cost

The excerpts of the document and the document are the property of the U.S. government and is licensed under a Creative Commons Attribution ShareAlike 3.0 (CC-BY-SA). For more information see http://creativecommons.org/licenses/by/3.0/.

Without the first part – studio – now goes to the definition of the database.
First question: which data are? It then creates a list of all the data we need to register for the various objects-tables.
So if for example I have a register contact:

• contacts
1. name
2. surname
3. address
4. fax
5. phone
6. etc..

An important point to note is the granularity of data, that is if I write – for example – first and last name in separate fields or in a single, or if the address is comprised of city and state and ZIP code or all in separate fields.
This depends on which use you od of the database. If I send a mass email separated by ZIP code, or send letters saying “Dear -user-” I will certainly divide the fields. In principle, it is always safer to divide the fields.

During the field list, it appears that some have a limited possibility of choice: for example some employees will be part of the purchasing office, someone else of the office sales and so on. In this case it is more convenient to extract the field, and create a dedicated his table: the table will be then “Department”, while in the “Employees” will only present a related field.

Another point to consider is the reuse of data: if the contact becomes a customer in the future, it is preferable to reuse data already entered. So rather than create a Contacts table and a Customers table, you can create a table with only those partners and common data tables associated with specific data (a contact does not have the tax code, while a customer), as proposed by second of the texts mentioned in the previous post.
Alternatively, a simple field that allows you to choose: “customer”, “Contact”, “supplier”, etc., if we agreed to put all the fields that we need in the same table.

The range of software used on the Internet is growing, mainly due to increased available bandwidth, and are beginning to see management or ERP solutions. We may therefore occasionally have to evaluate the advantages and disadvantages of these solutions.

Benefits are mainly in the availability anytime and anywhere, in cost savings related to the server, installing and updating, eliminating the problems of backup. Advantages that will surely make a difference for those who do not have adequate infrastructure and should update it for those who must start from scratch and would like to defer the big investments, for those with a light but highly decentralized.

But there are also disadvantages?
Yes, especially related to the fact that our data are no longer in our hands. Both from a legal point of view (privacy rules), both from a practical point of view, namely, the availability of data. If for some reason it wanted to have a copy of the data, may be a problem, whether economic or of delivery. Moreover, in case of data loss, there may be no guarantee or reimbursement (if it make sense). It must also be considered the possibility of interruption of the broadband connection.

So you need to properly evaluate the choice. But there is an alternative that hasn’t these problems?
Yes: take advantage of the cloud, but keeping a way out. How? Using software available both on the cloud and in classic form, thus fully available for use on your own server.

OpenERP can be used on the cloud, but at the same time I can install it on my server or PC, thanks to the license OEPL (a variant of open source license). It’s so possible to do a backup of your data, directly executable without limitation, recover them on your server and start again.

. . . to make them better!
And ‘one of the rules and SQL databases in general: no redundancies.
This prevents errors, reduces time, you live better (a bit ‘, at least).

Nice, but how to apply it in a systematic way?
Changing way of thinking. Or at least, think about what you’re doing before you start to make files and folders, which are increasingly crammed with PCs.
If:

1. I do a document whose data are for the most part extracts (extractable) from existing records, then it is more efficient to connect the existing data and produce a report;
2. the contrary, I make a document “do-it-yourself, which in any case preferable to then connect to the practice of reference, so you can forget where you saved

For point 1. I have custom reports created me, and for point 2. I have a document management program related to my practice.
Too difficult? Take a look at OpenERP and you will see that it is not true. Not at all.

NB: Thanks to David Vignoni (david@icon-king.com) ICON KING – www.icon-king.com to see the beautiful arrow LGPL 2.1.