Какое расширение базы данных в PHP (mysqli, PDO и т. Д.) Лучше всего подходит для приложений уровня предприятия?

Question

Какое расширение базы данных в PHP (mysqli, PDO и т. Д.) Лучше всего подходит для приложений уровня предприятия?

0

Какое расширение БД PHP (mysqli, PDO и т.д.) является лучшим для приложения уровня предприятия? Важными чертами, которые мне приходят в голову, являются:

при активном обслуживании
Много документации и примеров.
Возможно, одобрены самими людьми Mysql.
Robust
масштабируемый

Itay Moav -Malimovka 25 нояб. 2009, в 01:24

Источник

Теги:

php

mysql

enterprise

php-extension

2 ответа

-5

Реальные корпоративные приложения требуют не только расширения базы данных, но и ORM. Я слышал о доктрине, но не могу сказать, стабилен ли он, потому что я не использовал его.

Я просмотрел функции, которые он предлагает, и кажется, что этот проект существует некоторое время, потому что он поддерживает ленивую загрузку, отношения "многие ко многим", наследование, которые являются функциями, которые большинство новых ORM не имеют.

kubal5003 24 нояб. 2009, в 22:48

2

Хм ... нет. ORM не является обязательным. Это просто один из способов решения проблемы. На самом деле самая большая проблема с ORM заключается в том, что они просто не масштабируются так, как это делают схемы SQL.
cletus 25 нояб. 2009, в 00:05
0

Доктрина довольно стабильна в наши дни - я не использовал новую версию Shiney 1.2, которая выглядит так, как будто в ней много нового, но 1.0 - надежный.
benlumley 25 нояб. 2009, в 00:06
3

На этой планете нет ничего, что требовало бы ORM. Это всего лишь один из способов обработки доступа к базе данных, который нравится многим людям. Я один из тех, кто этого не делает.
Jan Krüger 25 нояб. 2009, в 00:06
0

@cletus, конечно, поэтому нам нужен орм, который позволяет вам использовать секционированную схему?
benlumley 25 нояб. 2009, в 00:07
1

@cletus, @benlumley: ИМХО, ORM - это более простой (для некоторого определения) интерфейс с вашими данными. Применяется общий компромисс между простотой и возможностью оптимизации. Вы можете добавить все эти возможности оптимизации в свой ORM, но в какой-то момент он перестает иметь какое-либо преимущество перед прямым SQL.
Jan Krüger 25 нояб. 2009, в 00:12
0

«На этой планете нет ничего, что требовало бы ОРМ». Конечно. На планете также нет ничего, что требует каркаса, и на планете нет ничего, что требует ООП, так почему бы не использовать простой старый C для создания веб-сайтов?
kubal5003 25 нояб. 2009, в 00:23
0

Потому что ORM может быть болью в заднице, как только вы делаете что-то более сложное, чем простой SELECT . Лично я нахожу всю идею ОРМ чрезвычайно ограничивающей.
Andrew Moore 20 фев. 2010, в 19:23

Показать ещё 5 комментариев

Ещё вопросы

Хм ... нет. ORM не является обязательным. Это просто один из способов решения проблемы. На самом деле самая большая проблема с ORM заключается в том, что они просто не масштабируются так, как это делают схемы SQL.
Доктрина довольно стабильна в наши дни - я не использовал новую версию Shiney 1.2, которая выглядит так, как будто в ней много нового, но 1.0 - надежный.
На этой планете нет ничего, что требовало бы ORM. Это всего лишь один из способов обработки доступа к базе данных, который нравится многим людям. Я один из тех, кто этого не делает.
@cletus, конечно, поэтому нам нужен орм, который позволяет вам использовать секционированную схему?
@cletus, @benlumley: ИМХО, ORM - это более простой (для некоторого определения) интерфейс с вашими данными. Применяется общий компромисс между простотой и возможностью оптимизации. Вы можете добавить все эти возможности оптимизации в свой ORM, но в какой-то момент он перестает иметь какое-либо преимущество перед прямым SQL.
«На этой планете нет ничего, что требовало бы ОРМ». Конечно. На планете также нет ничего, что требует каркаса, и на планете нет ничего, что требует ООП, так почему бы не использовать простой старый C для создания веб-сайтов?
Потому что ORM может быть болью в заднице, как только вы делаете что-то более сложное, чем простой SELECT . Лично я нахожу всю идею ОРМ чрезвычайно ограничивающей.

longneck · Accepted Answer · 2009-11-25T02-41-00.000Z

1. under active maintenance

mysqli и PDO. если вы в конечном итоге используете фреймворк, он, вероятно, будет использовать mysqli.

2. A lot of documentation and examples.

mysqli и PDO.

3. Probably endorsed by the Mysql people themselves.

MySQLi. см. http://dev.mysql.com/doc/refman/5.0/en/apis-php.html

4. Robust

если я должен был указать на одно одиночное расширение PHP, которое отвечает на вопрос "какой из них наиболее часто используется и у кого больше всего людей, которые его проверяют на наличие ошибок?", мне нужно было бы проголосовать за mysqli. если у вас есть другое определение надежного, вам нужно будет разработать.

5. scalable

это зависит от того, что вы подразумеваете под масштабируемым. в перестрелке mysqli vs. PDO, mysqli имеет самую узкую базу кода и, следовательно, более масштабируема просто потому, что код легче. YMMV. IANAL.

но если вы хотите что-то, что поможет вам масштабировать (например, распределить нагрузку на пару серверов mysql), вам понадобится что-то, чтобы обернуть mysqli/PDO, потому что ничего на уровне mysqli/PDO/любого уровня не сделает это для вас.