Package Data | |
---|---|
Maintainer Username: | konstmal |
Maintainer Contact: | aaron@aejnsn.com (Aaron Johnson) |
Package Create Date: | 2018-04-20 |
Package Last Update: | 2018-05-07 |
Home Page: | |
Language: | PHP |
License: | MIT |
Last Refreshed: | 2024-11-23 03:12:16 |
Package Statistics | |
---|---|
Total Downloads: | 3,546 |
Monthly Downloads: | 1 |
Daily Downloads: | 0 |
Total Stars: | 0 |
Total Watchers: | 1 |
Total Forks: | 0 |
Total Open Issues: | 0 |
Note
This package is under development.
Postgresify is a package for Laravel and Lumen that extends support to some of the more useful PostgreSQL data types. This package allows you to leverage PostgreSQL's data types, such as point, inet, circle, etc., within Laravel's Schema Builder and retrieve meaningful data from Fluent/Eloquent.
Example Migration:
Schema::create('hotel_search', function (Blueprint $table) {
// ...
$table->point('geocode_coordinates');
$table->ipAddress('visitor_ip_address');
$table->circle('search_area');
$table->dateRange('reservation_period');
$table->money('budget');
// ...
});
Life's easier, right? The above use cases of PostgreSQL's types eliminate a few immediately noticeable headaches:
VARCHAR
here.DECIMAL(11,2)
or whatever people do these days.Now let's discuss the actual utility afforded by these additional types. PostgreSQL is nicely equipped with functions and operators for meaningfully working with these data types. This depends on the architecture of your environment, but these types combined with the functions/operators allow you to offload some work onto your database server--which might be faster and could reduce some responsibilities within your application's code. Your mileage may vary. See this StackExchange Q/A.
To install this package you will need:
This package is intended for PostgreSQL 9.4+.
Add this package to your composer.json
file as a dependency:
composer require aejnsn/postgresify dev-master
After installing via Composer, register Postgresify's DatabaseServiceProvider
in your config/app.php
configuration file like so:
'providers' => [
// Other service providers...
Aejnsn\Postgresify\DatabaseServiceProvider::class,
],
If you would like code completion in your IDE for the PostgreSQL types made available via Postgresify, be sure your migrations (or other uses of Illuminate's Schema Builder) use
the Aejnsn\Postgresify\Database\Schema\Blueprint
class as in this example:
<?php
use Aejnsn\Postgresify\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class CreateHotelsTable extends Migration
{
public function up()
{
Schema::create('hotels', function (Blueprint $table) {
$table->dateRange('reservation');
// Build your schema using PostgreSQL's awesome types...
});
}
// ...
}
The geometric types in PostgreSQL can give you a ton of power while reducing complexity in your application.
PostgreSQL's geometric types do not try to replace the need for PostGIS in cases where geographic calculations are performed. Remember this is geometric, not geographic--the Earth is not flat, or even a perfect sphere, it's an oblate spheroid (ellipsoid). That being said, don't use geometric types for heavy geographic work. Please use PostGIS if you determine a need, your accuracy depends on it. For those of you would-be geodesy aficionados, check out Charles F. F. Karney's work. Karney's algorithms are accurate to within 15 nm.
Methods of storing currency in an application/database make a hot topic for debate, and there is a ton of misinformation on this topic. People start citing GAAP, and then it boils down to developers' non-standard preferences. There is too much uncertainty, and I just do not like it. Let's look at some common methods for storing currency:
float
. Don't do this, you'll have garbage for accuracy.decimal
/numeric
. This is fine and handles the cases where you need to store fractions of a
cent. Decimal can be a hit to your performance in analytical operations.integer
using cents (or other currency's base unit) or use money
. This is best, and works in
cases where you do not need fractions of a cent. PostgreSQL's money
stores as an integer (of cents) but cleans
up the display and return of doing so. Money
is more performant than decimal
. The range of money
is
-92233720368547758.08 to +92233720368547758.07, so yeah, it will handle large amounts.Network addresses can be a pain to work with. Imagine the use case where you would need to query all IP addresses of a certain subnet mask. PostgreSQL has Network Address Functions and Operators for purposes like this.
I made a pull request for the IP and MAC address types in Laravel. So these two types will be in your initial Laravel installation (5.2.27+), and should work across all of Laravel's supported database systems. However, PostgreSQL, unlike other database systems, has its rich set of network address functions and operators built-in.
Ranges are quite powerful. A range includes a lower-bound and an upper-bound, either of which can be inclusive or exclusive. It would take four columns to build that functionality without a range type. Check out PostgreSQL's Range Functions and Operators documentation.