Próbuję odnaleźć najlepszy sposób wymiany wartości cenowych między skryptem a bazą danych

konwersja przecinka na kropkę podczas operacji zapisu oraz na odwrót podczas prezentacji, na dłuższa metę wydaje się być łopatologicznym podejściem do sprawy.

Czytałem kiedyś o inicjowaniu zmiennych regionalnych które wpływały na format daty nie mogę sobie przypomnieć czy wpływały także na interpretacje przecinka jako kropki

i stad moje pytanie czy istnieje jakiś prosty sposób aby peHap rozpoznał liczbę zmiennoprzecinkową rozdzieloną przecinkiem jako float ?

a jeżeli nie to jak sobie radzicie z w/w przypadkiem

[PHP] pobierz, plaintext 
<?php
$numbers = array(
    '1,2',
    '3.4',
    5.6
);
var_dump($numbers);
/*
array(3) {
  [0]=>
  string(3) "1,2"
  [1]=>
  string(3) "3.4"
  [2]=>
  float(5.6)
}
 */
var_dump(floatval($numbers[0]));
//float(1)
var_dump(floatval($numbers[1]));
// float(3.4)
var_dump(floatval($numbers[2]));
// float(5.6)
$suma = floatval('1,5') + floatval('1,5');
var_dump($suma);
// float(2)
$suma = 1.5 + 1.5;
var_dump($suma);
// float(3)
(float) $a = '1,5';
(float) $b = '1,5';
var_dump($a+$b);
// int(2) - :)
?>
[PHP] pobierz, plaintext 

Nie. Musiałbyś cały programistyczny świat przewracać do góry nogami.

hm jeśli chodzi o przecinki to zawsze możesz zastosować funkcje number_format
number_format

osobiście kiedyś zastosowałem tą funkcję na stronie i działa do dziś (a działa zarówno przed wprowadzeniem do bazy jak i przy pobraniu z bazy)

Ja czasem używam:

[PHP] pobierz, plaintext 
<?php
function toFloat($price){
    $price = trim($price);
    if(preg_match("~^([0-9]+|(?:(?:[0-9]{1,3}([.,' ]))+[0-9]{3})+)(([.,])[0-9]{1,2})?$~", $price, $r)){
        if(!empty($r['2'])){
            $pre = preg_replace("~[".$r['2']."]~", "", $r['1']);
        }else{
            $pre = $r['1'];
        }
        if(!empty($r['4'])){
            $post = ".".preg_replace("~[".$r['4']."]~", "", $r['3']);
        }else{
            $post = false;
        }
        $form_price = $pre.$post;
        return $form_price;
    }
    return false;
}
?>
[PHP] pobierz, plaintext 

Pytanie tylko z czego wynikają te różnice w zapisie liczb. Bo rozumiem, że w bazie danych do przechowywania liczb używasz pola liczbowego, a nie varchar?
Po pobraniu z bazy możesz na tych danych wykonywać normalne operacje arytmetyczne.
Odebrane np. z formularza dane tak czy siak musisz przefiltrować, więc czy dasz jeden str_replace mniej czy więcej, to chyba bez większej różnicy?
Jedyny problem to wyświetlanie, ale tu przychodzi z pomocą wspomniany wcześniej number_format" title="Zobacz w manualu PHP" target="_manual.

@Vengeance,
czy rzeczywiście potrzeba tylu preg'ów do przekonwertowania zmiennej na float'a?

Jeżeli ktoś wpisze Ci:
1000.00
1 000.00
1,000.00
100.000.000,00

i tam rozne takie inne glupie kombinacje... to tak

Bardzo kolokwialnie jednak systemy operacyjne bardzo dobrze radzą sobie z tym w ramach ustawień regionalnych

trafiłeś, jednak dużo tłumaczenia z pewnych względów miałem liczby w bazie w postaci ###,##

jest to bardzo pozytywna funkcja i przyjmuje ustawienia regionalne

jezeli juz zachodzi u mnie potrzeba konwersji na float to korzystam z biorąc pod uwagę maskę dla wejścia #,#

[PHP] pobierz, plaintext 
<?php
public function cToP($val){
        return str_replace(',','.',$val);
    }
?>
[PHP] pobierz, plaintext 

rozwiązaniem które istotnie ma sens w takim razie to ustalenie na warstwie beforeFilter,Save, przeszukanie data z POST,GET i wychwycenie kluczy np currency oraz ich dalsza konwersja w zależności od potrzeby
[edit]
nie mialem czasu aby rozwinac, wiec jezeli posiadamy aplikacje w MVC oraz posiadamy front controller i tablice z post wszystkie wartosci cenowe puszczamy w tablicy data[model][currency_cena_netto] lub wydajniej data[model][currency][cena_netto] i tak jezeli front controller chwyci w befor save index z currency poddaje takie wartosci konwersji ... moze komus sie przyda

dziękować za dyskusje i rozwianie wątpliwości

Systemy tak, ale nie kompilatory, które traktują w 90% przypadków kropki jako separatory części dziesiętnych liczb.