Re: Enforcing uniqueness on [real estate/postal] addresses
There is also What3Words.com, which give a three word name to each 3m square over the world. Longer that USNG but easier to remember/type/say. David On Wednesday, 13 May 2020 14:33:30 BST Basques, Bob (CI-StPaul) wrote: > I've been following this thread with some interest. > > Was wondering if you ever thought about binding the textual address to a > USNG location. https://usngcenter.org/ > You can easily add individual locations within something like a farm field > with as few as eight unique digits that would identify each 10 meter > square. I'm oversimplifying my response, but once you look through how the > USNG works, you'll see the benefit for using it as a address/location > uniqueness enforcing tool. > It would easily allow for locating many different locations inside of a > larger addressed location, as well as non, addressed locations. The USNG > location can be thought of as a unique address unto itself, and works > across the planet. No two are alike. > > > Bobb > > > > -Original Message- > From: Peter Devoy > Sent: Tuesday, May 12, 2020 3:56 PM > To: Peter J. Holzer > Cc: pgsql-general@lists.postgresql.org > Subject: Re: Enforcing uniqueness on [real estate/postal] addresses > > Think Before You Click: This email originated outside our organization. > > > > >Is is possible to have two entries which have the same > >address_identifier_general, street and postcode, but different > >descriptions? > > > Unfortunately, yes. The data comes from gov't systems to regulate the > development/alteration of arbitrary pieces of property and those pieces do > not always have a postal address. E.g. a farmer may one year apply to > erect a wind turbine in "field north of Foo Cottage" and the next year > apply to demolish "barnhouse west of Foo Cottage". > Now, I know what you are thinking, there is a normalization opportunity and > you may well be right. However, the problem does exist in some of the other > fields too and I am already facing a fair amount of join complexity in my > schema so I am trying to figure out my options :) > > >(What is an address_identifier_general, btw?) > > Address identifier composed by numbers and/or characters. I'm using the > terminology from the EU's "INSPIRE Data Specification on Addresses" > Guidelines. > I haven't yet had the opportunity to try out the above suggestions but I > will post again when I have. >
Re: PL/java
As of Java-16 there is a replacement for JNI which allows direct calling of native interfaces without the need for hand coded stub code. On Monday, 7 December 2020 22:10:01 GMT Martin Gainty wrote: > Nota Bene: > Almost all official interfaces to/from Oracle are coded in Java > FWIK google's implementations are 95% python > (although you would need to understand JSON formatting for import/export > requirements) for those reasons i tread lightly before disparaging either > language > > Going Forward: > try to implement PL/SQL that rob/joshua mentioned > if you're calling no-joy after implementing PL/SQL > then we can take a look at interfacing to Postgres ETL binaries with a JNI > interface provided the JNI is spot on with signatures for each referenced > function > > Un Saludo > m > > > From: Rob Sargent > Sent: Monday, December 7, 2020 11:16 AM > To: pgsql-general@lists.postgresql.org > Subject: Re: PL/java > > On 12/7/20 8:25 AM, Adrian Klaver wrote: > > On 12/7/20 7:18 AM, Hemil Ruparel wrote: > >> I want to say this. I never liked any extension language. It's like > >> Java is not meant to interact with databases. > > > > The JDBC folks might disagree. > > That interaction is strictly sql to db, data to app. As it should be.
Re: The tragedy of SQL
On Tuesday, 14 September 2021 14:06:13 BST Merlin Moncure wrote: > On Tue, Sep 14, 2021 at 12:32 AM Guyren Howe wrote: > > If I had $5 million to invest in a startup, I would hire as many of the > > core Postgres devs as I could to make a new database with all the > > sophistication of Postgres but based on Datalog (or something similar). > > (Or maybe add Datalog to Postgres). If that could get traction, it would > > lead in a decade to a revolution in productivity in our industry. > I've long thought that there is more algebraic type syntax sitting > underneath SQL yearning to get out. If you wanted to try something > like that today, a language pre-compiler or translator which converted > the code to SQL is likely the only realistic approach if you wanted to > get traction. History is not very kind to these approaches though and > SQL is evolving and has huge investments behind it...much more than 5 > million bucks. > > ORMs a function of poor development culture and vendor advocacy, not > the fault of SQL. If developers don't understand or are unwilling to > use joins in language A, they won't in language B either. > > merlin Back in the day, within IBM there were two separate relational databases. System-R (which came from San Hose) and PRTV (the Peterlee Relational Test vehicle). As I understand it SQL came from System-R and the optimizer (amongst other things) came from PRTV. PRTV (https://en.wikipedia.org/wiki/IBM_Peterlee_Relational_Test_Vehicle_(PRTV)[1]) did not use SQL, and was never a released product, except with a graphical add-on which was sold to two UK local authorities for urban planning. So there are (and always have been) different ways to send requests to a relational DB, it is just that SQL won the day. [1] https://en.wikipedia.org/wiki/IBM_Peterlee_Relational_Test_Vehicle_(PRTV)
