Сообщения

Сообщения за январь, 2016

Yii 2 редактируемое дерево категорий

Изображение

Yii 2 связные списки с kartik\depdrop

Изображение

Yii2 сохранение многие-ко-многим в одной модели

Изображение

Yii 2 множественные модели в одном экшене

1. В контролере подключить обе модели 2. Поменять действия контролера 3. Подключить атрибуты в view\create 4. В _form можно использовать строки из обеих таблиц 1. Контролер <?php namespace app\modules\proj\controllers ; use Yii; use app\modules\proj\models\Human; use app\modules\proj\models\HumanSearch; use app\modules\proj\models\Passport; use app\modules\proj\models\PassportSearch; use yii\base\Model; use yii\web\Controller; use yii\web\NotFoundHttpException; use yii\filters\VerbFilter; /** * HumanController implements the CRUD actions for Human model. */ class HumanController extends Controller { public function behaviors () { return [ 'verbs' => [ 'class' => VerbFilter :: className(), 'actions' => [ 'delete' => [ 'post' ], ], ], ]; } /** * Lists all Human models

Естественные ключи против искусственных ключей

Данная статья излагает взгляд автора на проблему, регулярно обсуждающуюся в группах новостей, посвящённых разработке приложений с использованием РСУБД. О сущности проблемы Каждая запись в таблице, входящей в РСУБД, должна иметь первичный ключ (ПК) - набор атрибутов, уникально идентифицирующий её в таблице. Случай, когда таблица не имеет первичного ключа, имеет право на существование, однако в данной статье не рассматривается. В качестве первичного ключа может использоваться: Естественный Ключ (ЕК) - набор атрибутов описываемой записью сущности, уникально её идентифицирующий (например, номер паспорта для человека); Суррогатный Ключ (СК) - автоматически сгенерированное поле, никак не связанное с информационным содержанием записи. Обычно в роли СК выступает автоинкрементное поле типа INTEGER. Есть два мнения: СК должны использоваться, только если ЕК не существует. Если же ЕК существует, то идентификация записи внутри БД осуществляется по имеющемуся ЕК; СК до

Правила именования объектов базы данных

Прямая копипаста  Обсуждаемый вопрос заключается в следующем. Если мы начали разработку базы данных для некоторой задачи, определились с набором схем, таблиц, полей, внешних ключей, то как нам следует называть все эти объекты, и зачем вообще нужно говорить о какой-то особой системе наименований? Проблема чем-то похожа на выбор имен для переменных при написании программного кода. Но разница в том, что в написании процедур мир давно уже пришел к идее локальных переменных, и их имена остаются на совести автора-программиста - согласуются только параметры вызова. А вот база данных - штука глобального характера. Имена таблиц и полей используются в процедурах обработки, в клиентских формах ввода, в отчетах. Стройная система имен позволит "протащить" логику организации данных сквозь весь проект, сделать все его части более читабельными, за что вы получите немало благодарностей как от коллег по команде, так и от себя лично, когда вернетесь к задаче эдак через полгодика. С другой