My name is Vasyl Khrystiuk‎ > ‎process‎ > ‎main‎ > ‎

site-lib


Проблемы:

лень

как назвать таблицу со связями


http://stackoverflow.com/questions/1764483/
Кратко: есть таблицы Users, Roler и UserRoles, в которой очень вероятно что нет id(так как поиск всегда будет произведен по внешних ключах, как и удаление, а обновление не имеет смысла)

дока по PDO:
http://php.net/manual/ru/book.pdo.php
http://proft.me/2008/11/28/primery-ispolzovaniya-pdo/

Настоящая БОЛЬ с join table

Вообще, я знаю, что это и зачем оно, но такой екскурс, что изначально главную задачу join table можно выполнить и без join table а просто сделав выборку значений сразу с нескольки таблиц, указав условия выборки, которые могут определять характер ограничений. Более того (для меня) такая запись БОЛЕЕ ОЧЕВИДНА чем использование join table(в данном случае исключительно речи идет об inner join). Недостатки такого подхода более интересны и начинаются, когда вам надо сделать не inner join. Для сохранения прежнего вида запроса сначала прибегают к UNION такой же выборки только с ограничением на NULL и захардкоженными(почему этого слова все еще нет в словаре русского языка?) недостающих значений как NULL. Т.е. мы приходим к выводу что лучше изначально использовать join table, на всякий случай, если требования изменятся. Если. Если. Если. На практике же это вряд ли когда-нибудь произойдет и код написанный сложной выборкой, то вряд ли будет изменятся и все так же будет работать как часы, а читаться будет намного проще.

https://ru.wikipedia.org/wiki/Join_(SQL)
http://www.w3schools.com/sql/sql_join.asp
Еще немного обсуждений на эту тему: http://stackoverflow.com/questions/1018822/inner-join-on-vs-where-clause (п.с.: у большинства из них другое мнение... ну что ж, так и быть)
Впрочем, есть статья, которая таки доказывает преимущество inner join над where http://sqlblog.com/blogs/aaron_bertrand/archive/2009/10/08/bad-habits-to-kick-using-old-style-joins.aspx

Хороший блог об базах данных: http://sqlblog.com/blogs/aaron_bertrand/ надеюсь у меня будет когда-то необходимость в его прочтении. 



особенности alter table в sqlite

alter table add unique constraint sqlite
НЕ ПОДДЕРЖИВАЕТСЯ, потому надо изначально делать:
sqlite create table unique column

исключения при запросах в PDO

По дефолту они отключены, потому надо проверять руками после каждого запроса еррор код, либо добавить свойство определить другую реакцию на ошибку, чем дефолтная(ERRMODE_SILENT): 
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
либо же
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING);


колонки в css

Изначально я слаб в этом. Знаю что кроме absolute layout еще можно использовать display: inline-block и float. Оба способы хороши и работают отлично. Я, конечно же, не профессиональный верстальщик. Более того, тот же твиттер бутстрап для своих колонок использует именно display: inline-block и float. Но если попытаться таки разобраться:
http://somacss.com/cols.html
Так как absolut это слишком для меня(слишком грубое решение, которое требует слишком много работы), то я применил второй способ и.. Изначально у меня возникла проблема с заполнение одним элементом оставшегося места:
http://stackoverflow.com/questions/13402647
Там нет правильного ответа, потому я его дам:
Изначально, объявляя элемент float мы делаем его "рисунком", т.е. собственно тем, для чего этот стиль и придуман. Элемент, конечно же не станет рисунком, но все вокруг начнет думать что это так. Одно из интересных последствий - рядом стоящий текстовый блок уступая место "картинке", все же рисует свою рамку в том числе и вокруг него. 
    Это происходит по двум причинам. Первая уже озвучена: левый блок ведет себя как картинка. Второй блок же, соответствии со своим дефолтным правилом overflow: visible; разрешает отображение контента за границей блока, т.е. левая картинка, занимает некоторое место, и так как она с свойством float, то текст и все блоки рядом, соответственно, могут её обтекать, а значит по дефолту рассматривается такой сценарий:


    Избавиться от этого очень просто: нужно изменить дефолтное overflow: visible; на любое другое значение, например на overflow: auto; которое не разрешает отображение контента за пределами блока и добавляет прокрутку при необходимости:
    Ну и так как ни один из предков нашего текстового блока не определял правила на высоту, то скролбар будет применен сразу на всю страницу(т.е. его поведение скролбара не изменится, но обтекание пропадет).
    Отдельный случай, если картинка будет внутри такого текстового блока а не рядом. Следуя все той же логике, если по дефолту картинка с float может выступать за границы текстового блока, то применение любого недефолтного правила заставит блок растягнуться, чтоб вместить картинку. Говоря об картинке здесь, я конечно же подразумеваю наш плавающий блок. Пример с этим случаем здесь: https://css-tricks.com/almanac/properties/o/overflow/ (см. абзац с названием "Float Clearing"). Эта проблема очень популярна и более того, имеет и решение, известное как "Clearfix", к слову, первый же ответ отсылает на статистику браузеров по поддержке flexbox, в соответствии с которой(96%) float больше не нужен.  

 


вывод сообщений при POST/REDIRECT/GET запросах

http://stackoverflow.com/questions/1058497/

в общем случае это решается двумя способами:
хранением сообщений в сессии
добавлением в урл идентификатора сообщения

и оба имеют недостатки
недостатком первого способа есть то, что при конкурентных запросах а рамках одной сессии на одной странице можно получить сообщения от другой. можно лимитировать: по источнику запроса(тип страницы), по реффереру, но первое решает проблему только в одном из сценариев - работает когда конкурентные запросы произведены из разных страниц, но не из одинаковой. второе же - очень привязано к реализации браузеров, ибо как известно, история с передачей рефферов при запросах, а особенно при редиректах - нигде не специфицирована
так же одним из последствий главного недостатка является не только то, что вы увидите сообщени не там, где они должны быть, но и то, что вы НЕ увидите сообщения там, где они должны быть, ведь очевидная реализация этого способа требует удаления сообщений из сессии сразу же после того как сообщения выедены


Добавления идентификатора сообщения в урл имеет совсем очевидный недостаток: при обновлении страницы вы получите все то же сообщение, и еще набор сообщений ограничен. 

Конечно первый способ является предпочтительней чем второй, но все зависит от реализации. И даже если некоторые сервисы используют предпочтительно первый способ, даже при этом в некоторых случая можно встретить и второй способ.
И еще одно - даже если вкладки браузера можно идентифицировать с помощью sessionStorage, это никак не решет нашу проблему конкурентных запросов. 

Еще одно: можно каждую вкладку идентифицировать по уникальному случайному фрагменту строки запроса и печеньке, которая будет увеличивать свое значение на 1 с каждым переходом. Как только ожидаемое значение печеньки при запросе не совпало, значит у нас новая конкурентная вкладка(как копия оригинальной) и её надо присвоить собственный идентификатор. На самом деле этот способ очень даже решает проблему, но я не знаю, в каком состоянии я должен быть, чтоб решиться его использовать. Над недостатками способа каждый пусть подумает сам. Та же проблема. но под другим запросом: 
http://stackoverflow.com/questions/368653

upd: 
добавлю еще два сценария:
первый - при ошибке на пост запрос сразу возвращать ответ, а для того, чтоб форма была одноразовой(или даже имела ограниченной строк жизни) - в форму добавлять скрытый параметр, случайное число, именуемое как nounce (спасибо за подсказку)
второй - добавлять в get запрос уникальный случайный идентификатор сообщения, да, сообщение можно все так же хранить в сессии а не в базе, но выводить сообщение только раз при запросе с этим таким ключем, иначе редирект на такой же гет, только без ключа



sql insert if not exist otherwise find and return id

Мда
В общем, мне надо ид записи из одной таблицы по полю. А если записи нет, то создать её и вернуть ид. В одном запросе.  
http://stackoverflow.com/questions/4596390/insert-on-duplicate-key-do-nothing
Я пришел к тому, что все делаю в два запроса. Смотри первый пункт списка. 

Множественный инсерт

Моим хотелкам нет предела. Мало того что я хочу получить ид запсиси или создать её, но я к тому же хочу сделать множественный инсерт в одном запросе в разные таблицы:
http://stackoverflow.com/questions/2044467/how-to-update-two-tables-in-one-statement-in-sql-server-2005
Когда мне стало понятно что там все мутно, я задался вопросом сделать множественный упдейт хотя бы в одной таблице:
http://stackoverflow.com/questions/3432/multiple-updates-in-mysql
Как видите, тут мне повезло больше. 
Но зачем?





Comments