ANN: PHP Generator for MySQL 14.10 released
Hi! SQL Maestro Group announces the release of PHP Generator for MySQL 14.10, a powerful GUI frontend for Windows that allows you to generate feature-rich CRUD web applications for your MySQL database. http://www.sqlmaestro.com/products/mysql/phpgenerator/ Online demo: http://demo.sqlmaestro.com/ PHP Generator for MySQL comes in both Freeware and Professional editions. The feature matrix can be found at http://www.sqlmaestro.com/products/mysql/phpgenerator/feature_matrix/ Top 10 new features: 1. New and updated controls. 2. Enhanced JavaScript API. 3. New security-related features. 4. Extended template management. 5. Multi-group menus. 6. New application-level events. 7. Custom CSS and JavaScript. 8. Usability improvements. 9. PHP Generator UI enhancements. 10. Support for PHP 5.6 and other core features. Full press-release is available at: http://www.sqlmaestro.com/news/company/php_generators_advanced_to_version_14_10/ Background information: --- SQL Maestro Group offers complete database admin, development and management tools for MySQL, SQL Server, PostgreSQL, Oracle, DB2, SQLite, SQL Anywhere, Firebird and MaxDB providing the highest performance, scalability and reliability to meet the requirements of today's database applications. Sincerely yours, The SQL Maestro Group Team http://www.sqlmaestro.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
MySQL Utilities 1.5.3 has been released
Dear MySQL users, MySQL Utilities version 1.5.3 is a GA release for Utilities 1.5. MySQL Utilities version 1.5.3 is compatible with MySQL Server versions 5.5 and greater. Python v2.6 and v2.7 are supported. In addition to server utilities, MySQL Utilities also contains MySQL Fabric: a framework for managing a collection of MySQL servers. MySQL Fabric is deployed as a separate service daemon that contains support for high-availability and sharding. MySQL Utilities and Fabric require Connector/Python 2.0.0 or higher. The management framework maintains a database of the routing and state information for the servers making up the system and provides an easy-to-use command line interface for adding, removing and organizing servers. High-availability is provided by continuously monitoring the servers and executing slave promotion when the master crashes and just as importantly automatically updates the state and routing information that gets messages to the right server. MySQL Fabric comes with built-in support for sharding either using ranges or consistent hashing and supports the sharding of multiple tables to ensure that rows with matching sharding keys are stored in the same shard. MySQL Fabric also contains support for global tables that are duplicated on all shards as well as the ability to synchronize schema updates across all of the servers. To provide high performance and avoid latency, transactions are directly routed by Fabric-aware connectors rather than routing via an external proxy. The connectors dispatch transactions to the correct shard, perform load-balancing, and handle read-write splitting. Currently there exists Fabric-aware versions of Connector/Python, Connector/Java, and Connector/PHP (through a Fabric-aware mysqlnd_ms plugin). MySQL Utilities v1.5.3 GA is available for download from http://dev.mysql.com/downloads/tools/utilities/ A brief summary of changes is listed below. Please check the CHANGES.txt file inside the distribution for a more complete list of changes. Changes in MySQL Utilities 1.5.3 (2014-11-04) Bugs Fixed * The MySQL Fabric installer failed to properly check for the required Connector/Python version. (Bug #19807933, Bug #74339) * Setting up a MySQL Fabric backing store would fail when the target MySQL instance used a unicode character set as the default. (Bug #19785686, Bug #74192) * The MySQLServer object created connections with "use_unicode=False", and as a consequence some statements returned fields in the bytearray format, as opposed to the expected strings or unicode fields. This unexpected field data type would sometimes cause problems with several modules, such as replication and high availability. (Bug #19774543, Bug #74255) * MySQL Fabric was improved to support AWS and Trove. Changes include no longer assuming that hosts have UUIDs, and plugin support was also added. (Bug #19589254) * The mysqldbcompare utility options related to comparing all databases on two servers were accidentally removed (e.g., --all, --exclude, and --regexp in a previous release, and they have since been restored. Additionally, the error handling and validation routines were improved. (Bug #19430737, Bug #73551) Documentation - Online: http://dev.mysql.com/doc/mysql-utilities/1.5/en/ The source distribution includes the manual pages for each utility under the docs/ folder. Reporting Bugs -- We welcome and appreciate your feedback and bug reports: http://bugs.mysql.com/ Enjoy! On Behalf of the MySQL/ORACLE Utilities and Release Engineering Team, Hery Ramilison -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: Using INTEGER instead of VARCHAR/DATE - is this a way to faster access?
> From: (Halász Sándor) h...@tbbs.net > > 2014/10/29 20:56 +0100, Zbigniew > if instead of textual labels I'll use SMALLINT as simple integer "code" for > each different "label" (and in my program a translation table)? > > This, in effect, is ENUM... Well, not really! With INTEGERs, your referential integrity is external to MySQL, and has to be managed. > ... and maybe is useful if the set of dates is well determined... I was not suggesting it for dates. The OP appeared to have a well-defined set of strings in a VARCHAR field â THAT is what I suggested ENUMs for! > There is a design cost in using ENUM: If you find that your first set of > dates is too small, later, with ALTER TABLE, you have to change the type. Again, the suggestion for ENUM was to replace a constrained set of VARCHARs, and yet, you raise a valid point. What is the update frequency of those VARCHARs? If you're adding them often â or if you need to occasionally change their value â I'd use another table with a reference. If they're immutable and new ones are not added often, there's no "design cost" at all to using ENUMs. I'd argue there's a higher maintenance cost to NOT using them! Jan Steinman, EcoReality Co-op -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: Using INTEGER instead of VARCHAR/DATE - is this a way to faster access?
- Original Message - > From: "Zbigniew" > Subject: Using INTEGER instead of VARCHAR/DATE - is this a way to faster > access? >> What about using ENUMs? They have nearly the performance of INTEGERs, but >> you don't have to maintain a string mapping in your programming logic. > > But are you able to estimate, what "boost" can i notice? 5% - or 50%, > or maybe even 500%? I'll give you an interesting reason to switch to ENUM (or smallint, if so inclined): Your data fields will be smaller. That not only means more records in a page (might be negligable), but more importantly, it'll make the index on that field smaller, meaning a) more of it will remain in memory and b) lookups on it will be marginally faster, too. I have no hard data on how it'll impact index performance (your dataset is yours to benchmark), but on one million of records (and you were talking several), a each byte saved is a megabyte of memory that can be used for other purposes, like data cache, which will speed up other things, too. -- Unhappiness is discouraged and will be corrected with kitten pictures. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
