As an IT developer for Fortune 500 corps, I avoided any software that used a proprietary database.
They're fine for minor applications and quick, user specific tasks. But, for an enterprise software system they don't make for a dependable foundation. It's like building a house on foundation of sand that can be washed away...
If Apple truly wants to enter the business realm, they will support a database structure or partner closely with an organization that does have a reliable database structure that can serve as a base for application development.
As an IT developer for Fortune 500 corps, I avoided any software that used a proprietary database.
They're fine for minor applications and quick, user specific tasks. But, for an enterprise software system they don't make for a dependable foundation. It's like building a house on foundation of sand that can be washed away...
If Apple truly wants to enter the business realm, they will support a database structure or partner closely with an organization that does have a reliable database structure that can serve as a base for application development.
Here are IBM's databases and Apple's Swift language + iOS brought together in IBM's MobileFirst initiative. FoundationDB is different. As I understand from the post it is meant to replace SQLite for applications' internal data storage needs and also to be scaled and customized for performance in Apple's own cloud businesses. That differs from competing with Oracle by launching an enterprise grade database solution.
A typical sort included Div, Dept, Last Name, First Name -- a total of ~100 passes through the sorter.
Makes me wonder if the whole process was really more efficient…
Of course it is more efficient. Who would dare unsort it after 100 passes through the sorter
You would maintain a master file of, say,Employee Filein the order sorted above...
Then if you needed to process in a different order, you would make a copy of [all or some of the fields] in the master file by processing the entire file through a reproducer machine which created duplicates at, AIR, 100 cards per minute -- 1,000 employees = 10 minutes to reproduce.
Then, you would sort the reproduced file, as needed and leave the master file unchanged...
Say you wanted to make weekly time cards.
1) The Employee File is maintained in Div, Dept, Employee#, Lastname, Firstname order (it also contains the employee's work shift and pay rate)
2) You reproduce the Employee File onto Time Cards (one card for each employee) -- using a patch panel to:
copy Div, Dept, Employee#, work Shift (only) -- No name data (to free up card space) No pay rate for security reasons
generate the current date
3) Then you merge each Time Card behind the corresponding Employee File card on a machine called a Collator. The Employee File was put in the primary feed, the Time Card File in the secondary feed.
4) The merged file is put through an interpreter machine which printed the Div, Dept, Employee#, work Shift from the Employee card onto each following Time card 5) Next, the merged file is returned to the Sorter where it is separated into the Employee File and Time card file (the Employee cards contain a special punch in one of the columns)
6) The Employee File is returned to its file drawer, unchanged. 7) The Time card file is picked up by a clerk who distributes the Time cardsto the various time clocks throughout the enterprise.
Whew!
Actually, it's a pretty slick well-designed process -- to compensate for the limited storage of the database: the 80-column punched card.
At the end of the week, the time cards are collected -- and that leads to a whole 'nother process...
A typical sort included Div, Dept, Last Name, First Name -- a total of ~100 passes through the sorter.
Makes me wonder if the whole process was really more efficient…
Of course it is more efficient. Who would dare unsort it after 100 passes through the sorter
You would maintain a master file of, say,Employee Filein the order sorted above...
Then if you needed to process in a different order, you would make a copy of [all or some of the fields] in the master file by processing the entire file through a reproducer machine which created duplicates at, AIR, 100 cards per minute -- 1,000 employees = 10 minutes to reproduce.
Then, you would sort the reproduced file, as needed and leave the master file unchanged...
Say you wanted to make weekly time cards.
1) The Employee File is maintained in Div, Dept, Employee#, Lastname, Firstname order (it also contains the employee's work shift and pay rate)
2) You reproduce the Employee File onto Time Cards (one card for each employee) -- using a patch panel to:
copy Div, Dept, Employee#, work Shift (only) -- No name data (to free up card space) No pay rate for security reasons
generate the current date
3) Then you merge each Time Card behind the corresponding Employee File card on a machine called a Collator. The Employee File was put in the primary feed, the Time Card File in the secondary feed.
4) The merged file is put through an interpreter machine which printed the Div, Dept, Employee#, work Shift from the Employee card onto each following Time card 5) Next, the merged file is returned to the Sorter where it is separated into the Employee File and Time card file (the Employee cards contain a special punch in one of the columns)
6) The Employee File is returned to its file drawer, unchanged. 7) The Time card file is picked up by a clerk who distributes the Time cardsto the various time clocks throughout the enterprise.
Whew!
Actually, it's a pretty slick well-designed process -- to compensate for the limited storage of the database: the 80-column punched card.
At the end of the week, the time cards are collected -- and that leads to a whole 'nother process...
I liked that That database can easily be migrated to today's relational database platforms: this is one-to-many relationship and Employee and Time Cards are separate tables (file drawers).
In the early versions of Filemaker Pro (when it was not relational) people have gone through the lazy way of storing detail data (of a master/detail relationship) in Filemaker's repeating fields, instead of a separate table. Obviously migrating that to a truly relational database would be a disaster: a lot of manual editing has to be done in Excel (fill down) or a lot of scripted processing on exported text files. In fact instead of using repeating fields, they could easily edit/extract related records from the separate table using Filemaker scripts (i.e. implement the relational data model on non-relational Filemaker using scripts)... Right tools did not prevent people from making bad database design decisions...
A typical sort included Div, Dept, Last Name, First Name -- a total of ~100 passes through the sorter.
Makes me wonder if the whole process was really more efficient…
Of course it is more efficient. Who would dare unsort it after 100 passes through the sorter
You would maintain a master file of, say,Employee Filein the order sorted above...
Then if you needed to process in a different order, you would make a copy of [all or some of the fields] in the master file by processing the entire file through a reproducer machine which created duplicates at, AIR, 100 cards per minute -- 1,000 employees = 10 minutes to reproduce.
Then, you would sort the reproduced file, as needed and leave the master file unchanged...
Say you wanted to make weekly time cards.
1) The Employee File is maintained in Div, Dept, Employee#, Lastname, Firstname order (it also contains the employee's work shift and pay rate)
2) You reproduce the Employee File onto Time Cards (one card for each employee) -- using a patch panel to:
copy Div, Dept, Employee#, work Shift (only) -- No name data (to free up card space) No pay rate for security reasons
generate the current date
3) Then you merge each Time Card behind the corresponding Employee File card on a machine called a Collator. The Employee File was put in the primary feed, the Time Card File in the secondary feed.
4) The merged file is put through an interpreter machine which printed the Div, Dept, Employee#, work Shift from the Employee card onto each following Time card 5) Next, the merged file is returned to the Sorter where it is separated into the Employee File and Time card file (the Employee cards contain a special punch in one of the columns)
6) The Employee File is returned to its file drawer, unchanged. 7) The Time card file is picked up by a clerk who distributes the Time cardsto the various time clocks throughout the enterprise.
Whew!
Actually, it's a pretty slick well-designed process -- to compensate for the limited storage of the database: the 80-column punched card.
At the end of the week, the time cards are collected -- and that leads to a whole 'nother process...
I liked that That database can easily be migrated to today's relational database platforms: this is one-to-many relationship and Employee and Time Cards are separate tables (file drawers).
Exactly!
In the early versions of Filemaker Pro (when it was not relational) people have gone through the lazy way of storing detail data (of a master/detail relationship) in Filemaker's repeating fields, instead of a separate table. Obviously migrating that to a truly relational database would be a disaster: a lot of manual editing has to be done in Excel (fill down) or a lot of scripted processing on exported text files. In fact instead of using repeating fields, they could easily edit/extract related records from the separate table using Filemaker scripts (i.e. implement the relational data model on non-relational Filemaker using scripts)... Right tools did not prevent people from making bad database design decisions...
I remember demoing FileMaker (then called NutShell) on a Mac, to the head of IT (then called Data Processing) for John Deere. He was blown away by the ability to draw the relationship arrows between the separate tables (then called Files).
A typical sort included Div, Dept, Last Name, First Name -- a total of ~100 passes through the sorter.
Makes me wonder if the whole process was really more efficient…
Of course it is more efficient. Who would dare unsort it after 100 passes through the sorter
You would maintain a master file of, say,Employee Filein the order sorted above...
Then if you needed to process in a different order, you would make a copy of [all or some of the fields] in the master file by processing the entire file through a reproducer machine which created duplicates at, AIR, 100 cards per minute -- 1,000 employees = 10 minutes to reproduce.
Then, you would sort the reproduced file, as needed and leave the master file unchanged...
Say you wanted to make weekly time cards.
1) The Employee File is maintained in Div, Dept, Employee#, Lastname, Firstname order (it also contains the employee's work shift and pay rate)
2) You reproduce the Employee File onto Time Cards (one card for each employee) -- using a patch panel to:
copy Div, Dept, Employee#, work Shift (only) -- No name data (to free up card space) No pay rate for security reasons
generate the current date
3) Then you merge each Time Card behind the corresponding Employee File card on a machine called a Collator. The Employee File was put in the primary feed, the Time Card File in the secondary feed.
4) The merged file is put through an interpreter machine which printed the Div, Dept, Employee#, work Shift from the Employee card onto each following Time card 5) Next, the merged file is returned to the Sorter where it is separated into the Employee File and Time card file (the Employee cards contain a special punch in one of the columns)
6) The Employee File is returned to its file drawer, unchanged. 7) The Time card file is picked up by a clerk who distributes the Time cardsto the various time clocks throughout the enterprise.
Whew!
Actually, it's a pretty slick well-designed process -- to compensate for the limited storage of the database: the 80-column punched card.
At the end of the week, the time cards are collected -- and that leads to a whole 'nother process...
Yes, it worked... Till some numbskull (or worse, a hippy) folded, spindled or mutilated one of the cards... Then it all went to hell -- and so did he... But it made for some great social minded commentary leading up to 1984...
rbparker said: That's why FileMaker (owned by Apple, the largest company in the world) has been profitable for 73+ quarters...
I make a living off of FileMaker and the changes in 16 (and 15 and 14), the new features they offer for mobility (iPad and iPhone via FileMaker Go) and the ability to web-enable any of my solutions via Filemaker WebDirect are flat-out amazing. No other platform offers this level of options, control and customization.
I would never consider any database for enterprise that did not have native php connectors. Database functions are only a part of web design. Using the built in web-enable features of FM doesn't make sense to me - too limiting. I use a lot of Javascript/Ajax as well as all kinds of include files, iframes, CSS, cookies, caching, redirects and meta data such as character sets, etc. Plus, there are literally millions of php/mysql examples online to research as well as millions of developers if you need to hire some help. FileMaker is very niche and not very fast or scalable for web deployment, especially for large databases or lots of concurrent users.
rbparker said: That's why FileMaker (owned by Apple, the largest company in the world) has been profitable for 73+ quarters...
I make a living off of FileMaker and the changes in 16 (and 15 and 14), the new features they offer for mobility (iPad and iPhone via FileMaker Go) and the ability to web-enable any of my solutions via Filemaker WebDirect are flat-out amazing. No other platform offers this level of options, control and customization.
I would never consider any database for enterprise that did not have native php connectors. Database functions are only a part of web design. Using the built in web-enable features of FM doesn't make sense to me - too limiting. I use a lot of Javascript/Ajax as well as all kinds of include files, iframes, CSS, cookies, caching, redirects and meta data such as character sets, etc. Plus, there are literally millions of php/mysql examples online to research as well as millions of developers if you need to hire some help. FileMaker is very niche and not very fast or scalable for web deployment, especially for large databases or lots of concurrent users.
Filemaker Pro has native SQL connectors over ODBC. You can directly update your mySQL databases from within Filemaker Pro if you have resolved your security concerns and if your hosting company provides outside access to its mySQL server. If not, you can export as .sql your whole online database via phpMyAdmin, download it via https, load it into your offline (local) mySQL server and connect to that local server from within FMPro. This way is more secure.
Maintaining a mirror of your web databases in Filemaker Pro will make you or your client immensely productive.
Comments
They're fine for minor applications and quick, user specific tasks. But, for an enterprise software system they don't make for a dependable foundation. It's like building a house on foundation of sand that can be washed away...
If Apple truly wants to enter the business realm, they will support a database structure or partner closely with an organization that does have a reliable database structure that can serve as a base for application development.
Then if you needed to process in a different order, you would make a copy of [all or some of the fields] in the master file by processing the entire file through a reproducer machine which created duplicates at, AIR, 100 cards per minute -- 1,000 employees = 10 minutes to reproduce.
Then, you would sort the reproduced file, as needed and leave the master file unchanged...
Say you wanted to make weekly time cards.
1) The Employee File is maintained in Div, Dept, Employee#, Lastname, Firstname order (it also contains the employee's work shift and pay rate)
2) You reproduce the Employee File onto Time Cards (one card for each employee) -- using a patch panel to:
- copy Div, Dept, Employee#, work Shift (only) -- No name data (to free up card space) No pay rate for security reasons
- generate the current date
3) Then you merge each Time Card behind the corresponding Employee File card on a machine called a Collator. The Employee File was put in the primary feed, the Time Card File in the secondary feed.4) The merged file is put through an interpreter machine which printed the Div, Dept, Employee#, work Shift from the Employee card onto each following Time card
5) Next, the merged file is returned to the Sorter where it is separated into the Employee File and Time card file (the Employee cards contain a special punch in one of the columns)
6) The Employee File is returned to its file drawer, unchanged.
7) The Time card file is picked up by a clerk who distributes the Time cards to the various time clocks throughout the enterprise.
Whew!
Actually, it's a pretty slick well-designed process -- to compensate for the limited storage of the database: the 80-column punched card.
At the end of the week, the time cards are collected -- and that leads to a whole 'nother process...
In the early versions of Filemaker Pro (when it was not relational) people have gone through the lazy way of storing detail data (of a master/detail relationship) in Filemaker's repeating fields, instead of a separate table. Obviously migrating that to a truly relational database would be a disaster: a lot of manual editing has to be done in Excel (fill down) or a lot of scripted processing on exported text files. In fact instead of using repeating fields, they could easily edit/extract related records from the separate table using Filemaker scripts (i.e. implement the relational data model on non-relational Filemaker using scripts)... Right tools did not prevent people from making bad database design decisions...
I remember demoing FileMaker (then called NutShell) on a Mac, to the head of IT (then called Data Processing) for John Deere. He was blown away by the ability to draw the relationship arrows between the separate tables (then called Files).
Maintaining a mirror of your web databases in Filemaker Pro will make you or your client immensely productive.