Да, утверждаю что PHP это грааль.

[Polar]

А по факту заходишь в АОТ раздел таблицы, а там всего лишь один единственный класс с названием Таблица. И какое название ему в конструктор передашь - такой класс он тебе и создаст.
А еще вторым параметром ему передаешь коннект из какого сервера и какой базы тебе эта таблица нужна (т.е. совсем на другой сервер и на другую базу). И уже импорт/экспорт не нужен, а всегда актуальные данные. Можно одни таблицы держать на одном сервере БД, а другие на другом. А еще можно будет сделать, что одни таблицы в MySQL, другие в MSSQL, третьи на Oracle, а код пишешь как-будто все в одном.
В результате меньше кода, меньше ошибок, скорость больше, нагрузка меньше, больше эффекта за то же время.

[macklakov]

Цитата:

Сообщение от Polar

из какого сервера и какой базы тебе эта таблица нужна (т.е. совсем на другой сервер и на другую базу). И уже импорт/экспорт не нужен, а всегда актуальные данные..

Программистов что, совсем не учат теории надежности? Microsoft тоже эту подлянку себе регулярно устраивает.
Тут вот какое дело. С ростом количества вазаимозависимых компонентов, вероятность сбоя системы растет экспоненциально. Именно поэтому на многих производтсвах такое истеричное онтошение к качеству. Всякие Six Sigma вводят и прочее. Это происходит из-за того что иногда систему не получается упростить и приходится наращивать надежность каждого из компонент.
Но намеренно вводить в систему дополнительные зависимости, это значит гробить ее надежность прямо на старте. У вас одна из баз сбойнет и все остальное встанет. Или соединение с одной из баз сбойнет.

[Polar]

Цитата:

Сообщение от macklakov

Программистов что, совсем не учат теории надежности? Microsoft тоже эту подлянку себе регулярно устраивает.
Тут вот какое дело. С ростом количества вазаимозависимых компонентов, вероятность сбоя системы растет экспоненциально. Именно поэтому на многих производтсвах такое истеричное онтошение к качеству. Всякие Six Sigma вводят и прочее. Это происходит из-за того что иногда систему не получается упростить и приходится наращивать надежность каждого из компонент.
Но намеренно вводить в систему дополнительные зависимости, это значит гробить ее надежность прямо на старте. У вас одна из баз сбойнет и все остальное встанет. Или соединение с одной из баз сбойнет.

Майкрософт тебе совсем мозг деформировала.
Есть два подхода в создании систем.
1. Если в процессе что-то пошло не так, то программа падает и запускается снова.
2. Если что-то пошло не так, то боремся до последнего за живучесть системы и только потом падаем.

Ты думаешь все системы написаны в стиле майкрософта? Всегда чуть что и синий экран?
Прикинь так бы атомные станции строили? Дверью в подсобке не так хлопнул, и БАДАБУМ! Потом ждем период распада и строим новую станцию. )))

[macklakov]

Цитата:

Сообщение от Polar

1. Если в процессе что-то пошло не так, то программа падает и запускается снова.
....
Прикинь так бы атомные станции строили?

Во времена когда я еще был электронщиком, мы так примерно и проектировали. Чуть что, реактор гасится. Там задача обратная стояла и логика обратная. Сбой любой из подсистем роняет стержни чтобы остановить реакцию.

[Polar]

Цитата:

Сообщение от macklakov

Во времена когда я еще был электронщиком, мы так примерно и проектировали. Чуть что, реактор гасится. Там задача обратная стояла и логика обратная. Сбой любой из подсистем роняет стержни чтобы остановить реакцию.

Ну правильно. А мне ужасы расписываешь.
" У вас одна из баз сбойнет и все остальное встанет. Или соединение с одной из баз сбойнет."

Это с фига ли у меня все остальное встанет? Я же не использую майкрософт, и компоненты сам пишу с нуля.

[gl00mie]

Цитата:

Сообщение от Polar

один единственный класс с названием Таблица. И какое название ему в конструктор передашь - такой класс он тебе и создаст. А еще вторым параметром ему передаешь коннект из какого сервера и какой базы тебе эта таблица нужна (т.е. совсем на другой сервер и на другую базу). И уже импорт/экспорт не нужен, а всегда актуальные данные. Можно одни таблицы держать на одном сервере БД, а другие на другом. А еще можно будет сделать, что одни таблицы в MySQL, другие в MSSQL, третьи на Oracle, а код пишешь как-будто все в одном.

Закон Дырявых Абстракций приведет к тому, что надежность такой системы будет асимптотически стремиться к нулю, а жизнь людей в поддержке превратится в ад
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте"

[Polar]

Цитата:

Сообщение от gl00mie

Закон Дырявых Абстракций приведет к тому, что надежность такой системы будет асимптотически стремиться к нулю, а жизнь людей в поддержке превратится в ад
"Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте"

Это называется некрофилия. На дворе 2017 год, а ты выкопал статью от 2000 года. Причем там обосран и TCP и SQL. Ты ими не пользуешься? Фельдегерями пакеты шлешь, а данные в тетрадочке собираешь?

[gl00mie]

Цитата:

Сообщение от Polar

На дворе 2017 год, а ты выкопал статью от 2000 года.

Выходит, старые статьи плохи, и за 16 лет сложные абстракции перестали быть дырявыми?

Цитата:

Сообщение от Polar

Причем там обосран и TCP и SQL. Ты ими не пользуешься?

Тот же TCP там приведен в качестве примера сложной дырявой абстракции. Если отойти от статьи, то из моего скромного опыта поддержки и развития распределенных систем, любая связка со "сторонними" базами данных - это потенциальная проблема с производительностью/доступностью/надежностью/масштабируемостью. Можно долго и упорно настраивать индексы в "своей" базе, переписывать запросы и алгоритмы для снижения длительности блокировок, но потом какой-нить "умник" в сторонней базе забудет выставить уровень изоляции в READ_COMMITTED_SNAPSHOT, и твой код повиснет намертво при банальном чтении данных внутри транзации, а вместе с этим в твоей системе вырастет развесистое дерево блокировок и всё встанет колом.

PS. Хотя, конечно, в "песочнице" можно вообще, как 1С в свое время, использовать файловую БД и не париться - и так сойдет...

[ax_mct]

Цитата:

Сообщение от Polar

Майкрософт тебе совсем мозг деформировала.
Есть два подхода в создании систем.
1. Если в процессе что-то пошло не так, то программа падает и запускается снова.
...

Скорее всего имеется в виду модель работы PHP и того же Apache когда каждый запрос (GET/POST из браузера) изолирован и его падение не затрагивает сервер и другие запросы. Это особенность устойчивости PHP и соотносится с stateless природой web-протоколов.

А если речь о desktop приложениях и OS то мы лезем в дебри и вообще непонятно о чем говорим.

Цитата:

Сообщение от Polar

3-х звенную архитектуру знаешь? Что такое сервер приложений знаешь? Вот приложение это код на этом сервере.

Короче в терминах аксапты. Открываете АОТ в разделе таблицы, там структура таблиц описана. Закрываете. Перенастраиваете коннект на другую базу с совершенно другими таблицами. Открываете АОТ заходите в раздел таблицы, а там совершенно другие таблицы с другими полями и все уже описано за вас и ничего менять не надо.

Цитата:

Сообщение от Polar

А по факту заходишь в АОТ раздел таблицы, а там всего лишь один единственный класс с названием Таблица. И какое название ему в конструктор передашь - такой класс он тебе и создаст.
А еще вторым параметром ему передаешь коннект из какого сервера и какой базы тебе эта таблица нужна (т.е. совсем на другой сервер и на другую базу). И уже импорт/экспорт не нужен, а всегда актуальные данные. Можно одни таблицы держать на одном сервере БД, а другие на другом. А еще можно будет сделать, что одни таблицы в MySQL, другие в MSSQL, третьи на Oracle, а код пишешь как-будто все в одном.
В результате меньше кода, меньше ошибок, скорость больше, нагрузка меньше, больше эффекта за то же время.

Такие как бы динамичные Data Entity? Академически интересно, но практически:
- какие проблемы это решает?
- реальны ли эти проблемы?
- можно ли решить эти проблемы по другому?
- как данное усложнение помогает тебе реализовать твой бизнес-план?

Граальность PHP в стартаповости но с использованием популярных велосипедов.
Из Грааля надо пить, а не писать в него

[Polar]

Цитата:

Сообщение от ax_mct

Скорее всего имеется в виду модель работы PHP и того же Apache когда каждый запрос (GET/POST из браузера) изолирован и его падение не затрагивает сервер и другие запросы. Это особенность устойчивости PHP и соотносится с stateless природой web-протоколов.

А если речь о desktop приложениях и OS то мы лезем в дебри и вообще непонятно о чем говорим.

Вот именно! Похоже Маклаков вообще не в теме построения вебприложений.

Цитата:

Сообщение от ax_mct

Такие как бы динамичные Data Entity? Академически интересно, но практически:
- какие проблемы это решает?
- реальны ли эти проблемы?
- можно ли решить эти проблемы по другому?
- как данное усложнение помогает тебе реализовать твой бизнес-план?

Представляешь не надо мне теперь описывать структуру каждой таблицы в коде и изменения можно теперь делать только в базе данных а не поддерживать в актуальном состоянии все эти Data Entity. Какое же это усложнение? Я с себя кучу тупой работы скинул.

[ax_mct]

Цитата:

Сообщение от Polar

Вот именно! Похоже Маклаков вообще не в теме построения вебприложений.

Представляешь не надо мне теперь описывать структуру каждой таблицы в коде и изменения можно теперь делать только в базе данных а не поддерживать в актуальном состоянии все эти Data Entity. Какое же это усложнение? Я с себя кучу тупой работы скинул.

Не совсем понял как именно работает твое ORM (Object Relational Mapper),
но их много разных для PHP, неужели нет ни одного подходящего?

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

http://rohithegde.github.io/php-orm-comparison/
Doctrine (DataMapper pattern)
Propel (ActiveRecord pattern)
Redbean (DataMapper pattern)
Idiorm (ActiveRecord pattern but oriented towards Query Language)
Paris (ActiveRecord pattern & dependent on Idiorm)
Spot ORM (DataMapper pattern built on top of Doctrine DBAL)
Outlet (DataMapper pattern)
Xyster (DataMapper pattern)
Leap (Kohana FW)
Eloquent (Laravel FW)
MicroMVC
Gacela
NotORM

[ax_mct]

Цитата:

Сообщение от Polar

Представляешь не надо мне теперь описывать структуру каждой таблицы в коде и изменения можно теперь делать только в базе данных а не поддерживать в актуальном состоянии все эти Data Entity. Какое же это усложнение? Я с себя кучу тупой работы скинул.

То есть речь об автогенерации конкретного класса представляющего конкретную таблицу? Так достаточно других лентяев и соответственно созданных инструментов.
К примеру
Doctrine comes with a bunch of tools to help generate model classes from your existing database. http://symfony.com/doc/current/doctr...gineering.html

//-----
На предыдущие вопросы такие ответы?

- какие проблемы это решает?
Ответ: ускорение создания классов описывающих таблицы. Так?

- реальны ли эти проблемы?
Ответ: для некоторых программистов - да, для всех клиентов твоего бизнес-продукта - нет. Так?

- можно ли решить эти проблемы по другому?
Ответ: да. Проблема не уникальна, решения есть. Так?

- как данное усложнение помогает тебе реализовать твой бизнес-план?
Ответ: никак. Неоправданная трата времени на техническую реализацию ненужного.
Так?

А вообще правильное дело делаешь. Активная глупость бьет ленивый ум. Глупый умнеет, умный деградирует.

По архитектуре вот это забавно если с английским хорошо.
https://www.hakkalabs.co/articles/ro...ure-lost-years

Удачи!