Not to use sql.Null*** for storing value? about null

[guregu]

You can use JSON for persistence too. One of the original reasons I made this was to store the same data in SQL and MongoDB, which uses JSON. The types in this package also implement TextMarshaler which can be used for various storage packages.
Whether not you use the same structs for persistence and presentation is up to you. I don't prescribe any particular development philosophy here.
I embedded the sql.NullXYZ structs in the types here so it can be a drop-in replacement for them. This also means I don't have to re-implement their Scan methods, and we can benefit from any standard library improvements in new Go versions. It also serves to limit the scope of this library, instead of supporting every imaginable nullable type, we limit support to database/sql/driver.Value's types.
Personally I think the zero packages types are the most useful part of the this package, because you can decode Go-friendly JSON data straight into nullable SQL types without having to manually convert them all yourself. For example, you could use it to store data from a JSON file in an SQL database.
Because encoding/json's omitempty doesn't support non-pointer structs, this library is actually not great for presentation.

For greenfield development, I think it's best to eliminate nullable usage altogether and work with Go's zero values instead of against them. My original use-case was for interfacing with a legacy SQL database. You can also just use pointers.

I think eliminating the SQL dependency is completely fine if you want to focus on presentation, but until encoding/json is improved, pointers will likely be the better choice. Feel free to fork and experiment.

Also, when generics come with Go 2.0, I might experiment with generic nullable types and remove the embedded SQL stuff (or maybe make a new package). Until then, this project's API is unlikely to change.