User
Information
- Rating
- Does not participate
- Location
- Волжский (Волгоградская обл.), Волгоградская обл., Россия
- Works in
- Registered
- Activity
Specialization
ERP Developer, SAP-разработчик
Middle
From 1,000,000 ₽
ABAP
C++
C
PHP
Laravel
JavaScript
Web development
Ну так вы то уже сидите и вам всё-равно подняли там новую копибару или нет :)
На пикабу пост вида "а поставьте как мне плюсов" набрал более 10 тыс. плюсов. Но сомнительно что он "годный"
тут скорее интересно как выглядел задаваемый вопрос. Потому что по большому счету какая разница чей сервер, если он выполняет свои функции.
Модельки будут писать тексты, учитывая предпочтения пользователя. Т.е. одна статья будет для каждого выглядеть по разному.
Это проклятие больших компаний. Если они могут (а они могут ведь они большие), то они этим пользуются чтобы больше заработать.
Сотне таксопарков просто трудно договорится. Возможно кто-то и думает в эту сторону, но до реализации дело не доходит, потому что особой поддержки нет.
Это всё будет выглядеть одинаково на схеме.
Не стоит задачи показывать полную историю кто кого бросил, кто кого нагулял и т.д. и т.п., тут стоит задача сохранить генеалогическое и фамильное дерево чтобы посмотреть своих родственников. При необходимости можно создать вершину "неизвестный человек" и указать его как отца.
Я брал распространенные примеры, но мать тоже по тому же принципу указывается. Её, к примеру, могли лишить родительских прав, а ребенка усыновили в детдоме (рис.1) или ребенок остался с отцом после развода, отец заново женился и дочку удочерила новая жена (рис.2).
Ну и помимо "донора спермы" есть ещё , например, "суррогатное материнство". Там вообще не особо понятно. Вроде даже может и не быть генетического родства с матерью которая вынашивала ребенка. При этом схема всё равно применима. Если генетическое родство есть, то суррогатную мать указываем, если нет - можно её и вообще не указывать, потому что она ребенку никто.
Главное что схема всё-равно применима, даже к таким заковыристым случаям.
Судя по
затягивают там не айтишники. Просто кто-то изначально не продумал ТЗ
По сути всё привязано ко времени. Т.е. все связи между людьми, все атрибуты людей. Т.е. сегодня вы холостой, а завтра уже муж.
Как вариант, тут нужно делать ползунок с датой и чтобы отображалось состояние на указанную дату. И вот тут возникает вопрос, как показывать состояние объекта из будущего.
К примеру мы смотрим состояние на дату 1 мая, а свадьба 15 мая этого же года. Тогда отношение "брачная связь" будет находится в состоянии "неопределено" потому что она ещё даже не случилась. И тут я вижу два варианта:
1. Вообще не показывать
2. Добавить к состоянию активно/неактивно ещё состояние неопределено
Вариант 1 проще, но менее информативен.
Вариант 2 более информативен, но нужно придумать как лучше всего его отображать чтобы с одной стороны было видно что произойдет, а с другой что этого ещё не произошло.
и радоваться что хотя бы дожить эту жизнь разрешили
Тогда будет введена проверка перед проверкой, которая под закон попадать не будет
Первое правило - не снижай цену. Поэтому у него получается столько получать а у вас нет . :)
Остальные совета - только за деньги!
Грозило 35 лет, признал - получил 5. Интересная схема получения признания.
Для начала стоит проверить, а жив ли вообще абонент
К примеру массив в строку для SQL и в массив для PHP
Как раз изначально построитель запросов начал писаться чтобы вместо объектов получать именно отдельные поля таблицы с правильно конвертированными значениями PHP<=>SQL. Идея КЭШирования появилась потом. Но, на мой взгляд, эта весьма полезная фича.
Так что не получится
Закончилась эра шуток "яндекс не российская компания" ? :)
Поэтому этот сосед наверное и покатил бочку на того, что сообщил что дверь не закрыта. Потому что этот самый сосед предоставляет услуги хранения чужого добра у себя в квартире. А тут такой конфуз.
Скорее что дверь была не закрыта и он вошёл в прихожую. Увидел что там лежит мешок денег, вышел и позвонил хозяевам сообщив что они дверь не закрыли. А хозяева на него в суд за то что он вообще вошёл.