Using the Pythagorean formula on positions given in latitude and longitude makes as little sense as, say, computing the area of a circle using the formula for a square: although it produces a number, there is no reason to suppose it ought to work.
Although at small scales any smooth surface looks like a plane, the accuracy of the Pythagorean formula depends on the coordinates used. When those coordinates are latitude and longitude on a sphere (or ellipsoid), we can expect that
Distances along lines of longitude will be reasonably accurate.
Distances along the Equator will be reasonably accurate.
All other distances will be erroneous, in rough proportion to the differences in latitude and longitude.
The error depends on the start and end point of the distance calculations. However, because both the sphere and ellipsoid have a circular symmetry around the axis, the error depends only on the difference of the longitudes, so to study this error we might as well take the point of origin to be at the Prime Meridian. Because both the sphere and ellipsoid are symmetric under a north-south reflection, we only need to study points of origin in the southern hemisphere. For any such point we may draw a contour map of the relative error, equal to [Pythagorean calculation] / [True distance].
The Pythagorean formula, using the mean radius of the earth, is
Pythagorean distance = 6371000. * Sqrt[dx^2 + dy^2]] * pi / 180 meters
where dx is the difference in longitudes and dy is the difference in latitudes, both in degrees. (The difference in longitude values is reduced modulo 360 to give the correct value of dx when crossing the antimeridian; not doing so would introduce artificially large errors that tell us nothing about the Pythagorean formula itself.)
The following plots show the relative error compared to the correct distance on the WGS 84 ellipsoid for latitudes from -70 to 0 in increments of 10 degrees. The horizontal coordinate is the difference in longitudes and the vertical coordinate is the latitude of the destination. Light regions have relatively small error: the contour lines are at 1, 1.01, 1.02, 1.05, 1.1, 1.2, 1.5, 2, etc. (The pure white areas in the corners are places where the error goes beyond the range of these contours.) The red dots show the point of origin.
The vertical white bands testify to the correctness of expectation (1): Pythagorean distances are accurate when there is a small difference in longitudes. The horizontal white bands at low latitudes confirm expectation (2): near the Equator, horizontal distances are reasonably accurate. Otherwise, as witnessed by the extensive darker regions, at all other distances the Pythagorean formula is bad.
We can make quantitative estimates of the maximum error attained for pairs of nearby points (within, say, a few hundred kilometers of each other). Scale--using an appropriate value for the radius--is true along the meridian but along a circle of latitude it errs approximately by the secant of the latitude. For example, at a latitude of 40 degrees the secant is 1.31, implying the Pythagorean formula will give distances about 31% too large in the east-west direction. (This is evident in the upper right contour plot, for a point of origin at -40 degrees latitude, where the region immediately east-west of the red dot lies between the 1.2 and 1.5 contours.) Short distances in all other directions will be too large by some amount between 0% and 31%; longer distances may err by even more (as the contour plots show).
How about a method which is both more accurate and faster? This is
provided by GeographicLib. Comparative timings (C++
implementations on a 2.66GHz Intel processor, using g++) are:
Vincenty direct: 1.11 us
GeographicLib::Geodesic::Direct: 0.88 us
GeographicLib::GeodesicLine::Position: 0.37 us
GeographicLib::GeodesicLine::ArcPosition: 0.31 us
The accuracy of Vincenty's formulas is about 0.1 mm, while the accuracy
of the GeographicLib algorithms about 0.01 um. Geodesic::Direct does a
straight solution of the direct problem. It's somewhat faster than
Vincenty because it's non-iterative and because it uses Clenshaw
summation to evaluate the trigonometric series. GeodesicLine::Position
allows you to calculate many points along a single geodesic about
2.4 times faster. If you merely want some
points on a geodesic which are approximately equally spaced (e.g., for plotting it), you can use
GeodesicLine::ArcPosition and shave a little extra time off the
computation. You can reduce the time still further by reducing the order of the
series used by GeographicLib from 6 to 3 by compiling with
-DGEOGRAPHICLIB_GEODESIC_ORDER=3
The accuracy is then 0.04 mm, i.e.,
comparable to, but slightly better than, Vincenty.
A cookbook recipe for solving the equivalent problem on a sphere is
given by the Wikipedia entry on great-circle navigation.
Best Answer
With points as close as these we can ignore what type of spheroid the earth is and use the eqirectangular projection Pythagoras formula is all that is required.
The following two functions are in PHP.
As you can Equirectangular() is simpler than Haversine()and can be used for small distances. I have multiplied earth radius by 100 to convert to metres.
Result. Equirectangular 0.211513 m Haversine 0.211513 m The following code can be modified to suit your database