Previously on the blog
RSS feed
  1. Using POG with Flex
  2. Optimizing your web application
  3. Regenerating large objects
  4. PHP4 or PHP5
  5. New and Improved
  6. Evolution of a cube
  7. POG Museum
  8. POG 3.0 alpha
  9. Initial Performance results Part 2
  10. Initial performance results
  11. Proposal: POG 3.0 object model
  12. Suggest a feature
  13. A new year, A new POG release
  14. Many-Many relations
  15. POG 2.5 Released
  16. POG 2.5 beta
  17. Automatic table alignment
  18. New version: 2.1.2 released
  19. RSS should work well now
  20. RSS feed glitches
  21. What's new in 2.1.0
  22. PHP Objects 2.1.0 (preview)
  23. PHP Object relations FAQ
  24. PHP Object Relations
  25. Searching base64 encoded text
  26. How to debug POG-generated objects
  27. POG UI Tips
  28. Featuring Of Interest links
  29. PHP CRUD
  30. POG 2.0.1: A better code generator
  31. A look at the POG SOAP API
  32. POG 2.0.0 released
  33. Coming soon: Generate parent-child objects
  34. Generated abstraction v/s dynamic abstraction
  35. Zend Framework preview
  36. Coming soon: Generate Objects through SOAP
  37. Easily save images and files to a database
  38. PHP, Paypal & POG
  39. Five advanced Code Generator tips
  40. PHP Pagination using generated objects
  41. PHP Code Generator benchmarks
  42. Representing database objects using an AJAX Tree interface
  43. Using SETUP in a production environment
  44. Description of the generated object package
  45. Introducing PHP Object Generator version 1.6
  46. Using AJAX and PHP Object Generator
  47. When to use Object->SaveNew()
  48. Generating PHP objects in 2006
  49. Happy Holidays
  50. A short video of the POG Setup process
  51. A sneak peek at POG 1.6
  52. POG Tip: Field limits
  53. Previous versions.
  54. Searching the blog and tutorials sections
  55. Generating code with "Other" SQL data types
  56. Five general POG tips
  57. POG source code locations
  58. Microsoft SQL 2005 Express Edition
  59. Impatiently awaiting PHP 5.1 and PDO
  60. Php Object Generator goes open source
  61. POG generates PDO compatible code
  62. Oracle to offer free database
  63. POG Google group
  64. Database Wrappers and POG
  65. Revisions
  66. The generator blog
  67. An explanation of the 'Escape' function.
  68. Mirror, mirror
  69. Using POG to solve real world problems
  70. A php object-relational database tool
  71. A simple and flexible Object Oriented approach to PHP

Want more Php Object Generator?
Back to the Code Generator
The POG Google group
The POG tutorials/code samples
The POG mirror site

POG Tip: Field limits

written 4965 days ago

When defining objects, one aspect that even the most advanced programmers often overlook is that POG encodes and decodes object attributes on the fly on their way to and from the database using Base 64.

For example:
Movie Object—-> Title = Harry Potter

On its way to the database, POG encodes “Harry Potter” (12 characters) to “SGFycnkgUG90dGVy” (16 characters).

Therefore, it’s a good idea to provide on average 33% more space than what you would normally allocate if you weren’t using POG. *

For example, if you’re storing movie titles and you’re expecting the longest title that your website/webapp will support will be 100 characters long, you probably should be defining the ‘title’ attribute as VARCHAR ( 150 ) instead of VARCHAR ( 100 ). This will ensure that all your information is saved successfully. **

Similarly, if you modify the Escape and Unescape functions with your own encoding or encrypting functions, keep in mind that encoded or encrypted text is usually longer than their plain text counterpart.


*In our case, we believe that a 33% overhead is an acceptable price to pay for the convenience of not having to escape data manually. You may disagree and if you do, feel free to simply comment out the contents of the Escape and Unescape functions.

**Please note that objects generated for PHP 5.1 PDO do not have the Escape and Unescape functions currently. They will be included in POG 1.6 for consistency.

I have had some questions why we would want to escape the data that we store into the database. There are 3 main reasons that we do this.

* Data Integrity: simply that the conversion of text & binary information is retained in and out of any database using this type of encoding. Thus it is less trouble to pass/retrieve information to/from a database using encoding/decoding.

* Reduce hackability: we know that passing in direct text content into/out-of the database via inserts/selects could cause undesirable results and allow information to be inserted/recovered that shouldn’t otherwise be. When doing a security audit, this may become more obvious.

* Data obsfucation: There is a proposed law (i.e. in California) that [will] require data stored in databases to be unreadable by theives if the software is to be used in that state. The purpose of this is to protect personal privacy and information. Although this is not encryption, it is a step towards this end. At least it makes it more difficult to peruse at a glance.

I know that there are many arguments going each way and that picking one over another is difficult to always justify. That being said, the encoding has proven to be very useful in many situations and the performance cost has been quite minimal. There are also some clever optimizations that can be employed for transferring larger data bits more directly from the database to a remote client. Things that come to mind are SOAP transfers and images.
Mark Slemko    Dec 20, 06:27 AM    #

  Textile Help
About Php Object Generator
This is a weblog about the Php Object Generator (POG) project, OO PHP, databases and Php code generators in general.

Php Object Generator, (POG) is an open source PHP code generator which automatically generates clean & tested Object Oriented code for your PHP4/PHP5 application.

Subscribe to our RSS feed

Feedback, Feature Requests, Bugs to:
The POG Google group

Send us a Hello through email