Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM    Subskrybuj kanał ATOM dla tagu sql Kanał ATOM (tag: sql)

Autor wpisu: JoShiMa, dodany: 24.06.2016 01:01, tagi: framework, php, sql

Przymierzam się do kolejnego projektu w Yii, w którym będę wykorzystywać strukturę drzewiastą nested set i nagle okazało się, że potrzebuję bardziej skomplikowanych zapytań do bazy niż wykorzystywane ostatnio podstawowe CRUDy. Troszkę poszperałam, troszkę poczytałam i ku pamięci zanotuję. Jak w wielu (a może we wszystkich) frameworkach, w Yii można na różne sposoby pobierać dane […]

Autor wpisu: zleek, dodany: 22.12.2015 10:10, tagi: php, sql

Database queries usually are quite simple, but sometimes we have to build more complex queries. Let’s have an example We do have a search form where user can select one or many colours of product and one or many sizes.

Autor wpisu: Diabl0, dodany: 09.10.2015 14:46, tagi: php, sql

Pobieramy instantclient z strony Oracle (wymaga logowania). Ja korzystałem z wersji 11.2.0.4.0 (64-bit). Potrzebne nam są:

  • Instant Client Package – Basic: All files required to run OCI, OCCI, and JDBC-OCI applications
  • Instant Client Package – SDK: Additional header files and an example makefile for developing Oracle applications with Instant Client

Zawartość unzipujemy i kopiujemy do wybranej ścieżki (w moim przypadku /usr/local/instantclient)

Następnie tworzymy symlinki:

ln -s libclntsh.dylib.11.1 libclntsh.dylib
ln -s libclntsh.dylib libclntsh.so

I exportujemy ścieżkę aby pdo_oci odnalazło sobie instantclienta:

export ORACLE_HOME="instantclient,/usr/local/instantclient,11.2.0.4.0"

Teraz pozostało nam już odpalić instalację PHP, np. poprzez:

brew install php56 --with-pdo-oci

Oczywiście pozostałe opcje kompilacji (oraz wersję PHP) dobieracie pod swoje potrzeby.

 

Autor wpisu: zleek, dodany: 10.03.2015 10:48, tagi: sql

In many cases we store some additional data in tables, which are helpful for some management tasks. But sometimes those data are problematic, especially if we would lie to have unique data. Lets think about following case. We have table (user_log_table) in our database where we store all login and logout actions of our users. […]

Autor wpisu: zleek, dodany: 04.03.2015 10:52, tagi: sql

Sometimes there is a need to connect to other Oracle database from the current database. The case for that issue could be i.e. data migration between databases. So here is the short query to create the ling to other database: Description of variables: host: url to database which we want link to username: name of […]

Autor wpisu: matipl, dodany: 18.11.2013 09:32, tagi: php, mysql, sql

MariaDB - MySQL

W ostatnim czasie kilkukrotnie już zdarzyło się, że osoba z którą rozmawiałem sądziła, że MariaDB to zupełnie nowy silnik bazodanowy niekompatybilny z MySQL.

Nic bardziej mylnego. Sytuacja wygląda bardzo podobnie do tej z OpenOffice sprzed kilku lat. Jak pamiętacie w 1999 roku firma Sun Microsystems przejęła produkty firmy StarDivision i udostępniła pod nazwą StarOffice. Pakiet był darmowy, ale zamknięty ze silnym wsparcie od firmy Sun. W 2002 roku pojawiła się pierwsza wersja OpenOffice, na której bazował StarOffice 6.0. Był to bardzo popularny zabieg w tamtym czasie (patrz OpenSUSE, CentOS). Firma wydawała otwartą, darmową wersję community rozwijaną przez społeczność, następnie markowała swoją marką i rozprowadzała za odpowiednie benefity (często w formie płatnego supportu).

Nie wszystko układało się jednak najlepiej, ale w takim zawieszeniu środowisko współtwórców OO trwało przez wiele lat. W 2010 roku firma Oracle przejęła Sun i wszelkie projekty, w tym OpenOffice/StarOffice. Środowisko open-source było zaniepokojone poczynaniami Oracle (np. pozwy w sprawie korzystania z Javy w Androidzie) i postanowiono zupełnie oddzielić się od korporacyjnych wpływów – powstał LibreOffice.

To tak w sporym skrócie. Co wspólnego ma z tym MySQL? MySQL tworzony był przez szwedzką firmę MySQL AB, która została wykupiona przez Sun w 2008 roku, a ta została przejęta… Zgadza się, przez Oracle w 2010 roku. Ale już w 2004 roku środowisko wolnego oprogramowania zaczęło mieć „problemy” z MySQL, a dokładniej programiści chociażby PHP. Wszystko z powodu zmian w licencji MySQL od wersji 4.1, ponieważ od tego momentu MySQL na darmowej licencji można było używać wyłącznie do zastosowań niekomercyjnych. W momencie przejęcia przez Sun, jeden z twórców MySQL (Monty Widenius) stworzył forka MySQL pod nazwą MariaDB.

MariaDB

MariaDB jest oparta na tym samym kodzie co MySQL, ale rozpowszechniana tylko na licencji GPL. Twórcy starają się utrzymywać ciągłą kompatybilność do pierwowzoru – MySQL. Produkt ma być dostępny zawsze na licencji GPL, czego nie można powiedzieć o przyszłości MySQL od Oracle.

Do wersji 5.5 (aktualna stabilna) MariaDB jest numerowana identycznie do MySQL i kompatybilna w pełni. Natomiast następcą MariaDB 5.5 będzie MariaDB 10 (obecnie w fazie rozwoju, będzie częściowo kompatybilna z MySQL 5.6).

Percona Server

Firma Percona natomiast stworzyła fork MySQL zastępując jej silnik innoDB (względy licencyjne) silnikiem pisanym przez zespół XtraDB. Głównym powodem wprowadzenia własnych zmian była słaba skalowalność bazy MySQL w oryginale.

Percona Server jest w stanie skalować się aż na 48 rdzeni procesora. Podobnie jak MariaDB, również Percona Server od wersji 5.6 nie będzie w pełni kompatybilna z MySQL 5.6. Percona Server wykorzystuje natomiast dobre smaczki z MariaDB, oraz pewne udostępnione fragmenty kodu przez Google (np. SHOW USER/TABLE/INDEX).

Percona Server 5.5 udostępniona jest na wersji CC BY-SA 2.0.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: kicaj, dodany: 21.09.2013 12:30, tagi: sql, php

W poprzednim poście opisującym internacjonalizacje w Cake'u mogłoby się wydawać, że wyczerpałem temat. Jednak w używaniu Translate Behavior występują inne problemy, które należy rozwiązać - niestety samodzielnie. Pierwszy z problemów, który spotyka nas używając Translate Behavior jest brak możliwości zwracania treści tłumaczonych dynamicznie z modeli z którymi mamy relacje (hasMany i belongsTo).
Wszystkie wpisy należą do ich twórców. PHP.pl nie ponosi odpowiedzialności za treść wpisów.