



сегодня 10930 Подписчиков
Практическая реализация базы данных EAV по "Cычёвски"
Обсуждения-аналоги
-
+69 / 2017-11-05 14:00:28,
[не прочитана] -
+1 / 2010-02-23 11:56:47,
[не прочитана] -
+5 / 2017-11-05 14:00:28,
[не прочитана] -
+12 / 2017-11-27 18:03:24,
[не прочитана] -
+11 / 2017-11-27 17:49:19,
[не прочитана]
Авторы
Работая над разработкой мобильного приложения для Android и IOS, столкнулись с ситуацией, когда не понятно, какие данные нужно будет хранить в базе данных. Такая "неопределенность" не позволяет использовать обычные базы данных. Поэтому было принято решение использовать EAV модель хранения данных. На данном форуме была найдена модифицированная версия EAV базы данных. Она и была взята за основу.
- «Set_id» int(15);
- «Name_id» int(15);
- «Value_id» int(15).
Таблица «Values_string ». Поля:
- «Value_id» int(15), AUTO_INCREMENT;
- «val »varchar(255), пустые значения ДА, значение по умолчению NULL.
- $_phone_id = 1; $n_phone_id = "phone_id";
- $_nik_name = 2; $n_nik_name = "nik_name";
- $_name = 3; $n_name = "name";
- $_fname = 4; $n_fname = "fname";
- $_phone = 5; $n_phone = "phone";
- $_programm = 10; $n_programm = "programm";
- $_googl_id = 11; $n_googl_id = "googl_id";
- $_my_catalog = 20; $n_my_catalog = "my_catalog";
- $_catalog = 30; $n_catalog = "catalog";
- $_loc_x = 50; $n_loc_x = "loc_x";
- $_loc_y = 51; $n_loc_y = "loc_y";
- phone_id, nik_name, phone, loc_x, loc_y, и в базе есть пользователи, которые не задали еще nik и phone)
- {«00001», « Ваня», «78889995556», «30.34953», «40.23542»};
- {«00002», «», «78889995556», «30.34963», «40.45542»};
- {«00003», «Петя», «», «35.23453», «42.23232»}.
- {«00001», « Ваня», «78889995556», «30.34953», «40.23542»};
- {«00002», «77888454556», «30.34963», «40.45542»};
- {«00003», «Петя», «35.23453», «42.23232»}.
while ($res1=mysql_fetch_array($r1)) //перебираем пользователей
{
//это имена свойств
foreach($properties as $index => $property) //формируем массив с результатом
- {«phone_id:00001», «nik_name:Ваня», «phone :78889995556», «loc_x: 30.34953», «loc_y: 40.23542»};
- {«phone_id:00002», «phone : 77888454556», «loc_x: 30.34963», «loc_y: 40.45542»};
- {«phone_id:00003», «nik_name:Петя», «loc_x: 35.23453», «loc_y: 42.23232»}.
1. По поводу «данных, которых нет».
Эту проблему можно полностью решить на уровне пользовательского интерфейса. Если у некоторого типа наборов есть свойства, которые всегда должны быть, даже, если Пользователь не хочет их вводить, можно на уровне интерфейса задать им значение по умолчанию « » (пустая строка). Таким образом, у этих наборов всегда будет содержаться пустое свойство и вывод всегда будет следующего вида:
{«00001», «Ваня», «78889995556», «30.34953», «40.23542»};
{«00002», «», «78889995556», «30.34963», «40.45542»};
{«00003», «Петя», «», «35.23453», «42.23232»}.
2. По поводу получения всех свойств наборов.
Для чего в файле-справочнике записаны строковые имена? Ведь смысл файла-справочника именно в том, чтобы от них избавиться.
Вспомним еще раз, для чего нужны эти строковые имена. Они нужны для понимания ПРОГРАММИСТОМ И ТОЛЬКО ПРОГРАММИСТОМ того, с чем он работает. Ни пользователем, ни программой.
Поэтому давайте все таки уберем их из справочника и оставим так:
$_phone_id = 1;
$_nik_name = 2;
$_name = 3;
$_fname = 4;
$_phone = 5;
$_programm = 10;
$_googl_id = 11;
$_my_catalog = 20;
$_catalog = 30;
$_loc_x = 50;
$_loc_y = 51;
и модифицируем код следующим образом:
Во-первых, переименуем массив:
$properties = array($_phone_id,$_nik_name,$_phone,$_loc_x,$_loc_y)
следующим образом:
$names = array($_phone_id,$_nik_name,$_phone,$_loc_x,$_loc_y)
Ведь в нём, всё-таки, хранятся не свойства как таковые, а только их имена. На первый взгляд, это кажется незначительным и неважным изменением, но через некоторое время Вы увидите, насколько это упрощает понимание того, с чем мы работаем.
Во-вторых, поменяем само получение свойств:
foreach($names as $index => $name) //формируем массив с результатом
{
$r=get($_set_id, $name, null);
while ($res=mysql_fetch_array($r))
{
$set[$name] = $res["Val"];
}
}
OutResult($set);
Замечание: непонятная переменная $array здесь заменена на более понятную $set, опять-таки, из соображений читаемости.
Результатом будет массив с ключами, соответствующими именам свойств вида:
{[1]=>«00001», [2]=> « Ваня», [5]=> «78889995556», [50]=> «30.34953», [51]=> «40.23542»};
Теперь, если мы захотим получить некоторое конкретное свойство из этого массива, мы просто сделаем следующее:
$wanted_value = $set[$_phone];
Согласитесь, что, вопреки не вполне читаемой, на первый взгляд, структуре массива, нам вполне понятно, что мы только что из него достали.
Таким образом, в соответствующих полях можно легко отобразить данные, которые там необходимы с помощью чего-то вроде этого:
<form method="post" name="visualizwer">
<?
$texts = array(”ID телефона”,“Ник” ,”Номер”,”Широта”,”Долгота”);
foreach($names as $index => $name){
echo(
"<span>
<input
id =\"$any_id\"
name =\"$name \"
class =\"element text\"
placeholder = \"$texts[$index] \"
value =\"$set[$name]\"
type =\"text\"
size=\"60\">
</span>"
);
echo ("is selected $any_id.<br /><br />");
}
?>
Обратите внимание, что читаемые для человека названия свойств вводятся ЗА ШАГ ДО ИХ ОТОБРАЖЕНИЯ НА ЭКРАН, не раньше. Более того, здесь они понимаются не как «имена свойств», а как «указания для Пользователей». Они с таким же успехом могли быть следующего вида:
$texts = array(”Ваш уникальный АйДи”,“Ваш невероятный никнейм” ,”Ваш телефон”,”Ваша Широта”,”Ваша долгота”);
Эти читаемые имена свойств можно в принципе хранить и в самой базе. Ведь, если Ваше приложение работает с несколькими языками, эти надписи должны меняться в зависимости от языка.
3. По поводу добавления данных
Не совсем понятно, почему настолько разнятся алгоритмы для добавления и обновления данных. Ведь, когда мы обновляем данные, мы пишем их в указанную строчку, а когда добавляем, то сначала создаем строчку, а затем пишем данные в указанную строчку. Логика для этих двух случаев отличается лишь на одну операцию – генерацию нового ID.
4. По поводу функции GET
Вместо того, чтобы писать отдельный запрос (или отдельную функцию) для каждого случая, лучше написать составитель запросов, который будет автоматически создавать их в зависимости от переданных параметров.
В нашем "ядре" этим составителем является функция get_brick («кирпичик»). Она будет принимать на вход следующие параметры:
get_brick ($selects, $table, $where_keys, $where_values);
$selects - говорит нам: что мы должны выбрать;
$table – говорит нам: откуда выбирать;
$where_keys – говорит нам: какие ключи проверять у наших значений;
$where_values – говорит нам: какие значения должны быть у соответствующих ключей.
Имея такую функцию, мы можем просто менять передаваемые ей параметры, в зависимости от того, что мы хотим найти, а она уже составит нам запрос, к примеру вида:
SELECT VALUE_ID,VAL FROM VALUES_STRING WHERE VAL IN ('Дима');
Возвращаемый такой функцией результат мы уже потом раскладываем в читаемый для человека вид.
С Уважением,
Обращаем Ваше внимание: схожее обсуждение идёт также и в соседней "ветке".
Спасибо,
Планируются 2 бесплатных вебинара (каждый по продолжительности около 1 часа), посвящённые приложениям ТРИЗ к IT, в том числе, конкретным решениям:
1. Последней 5-ой версии "EAV as OWL’s" (в статье, которая здесь обсуждается, описана первая версия).
Эта версия, кроме уже того, что обсуждено здесь и описано в публикации, умеет делать автоматический умный шардинг в фоновом режиме, в том числе, между разными машинами; позволяет, если это кому-то необходимо, данные разных приложений хранить в одной базе или в общем «шардинговом пространстве» разных проектов. Например, это удобно для развивающихся проектов с разным ассортиментом для общих целевых групп.
Поскольку БД действительно не знает ничего о приложении, с которым работает, можно работать с данными, не думая о приложениях - с ними будет всё в порядке, а также можно «подружить» базы разных приложений.
"Симметрично", приложение действительно не знает ничего о том, откуда приходят данные и можно переписывать приложение, не думая о базе (база будет адекватной любому изменению.
Кроме того, мы предполагаем (не все тесты ещё проведены), что создаём архитектуру:
- потенциально самую компактную (соотношение полезных данных к общему объёму данных практически = 1)
- потенциально самую управляемую (управляемость не усложняется и при петабайтах данных)
- самую быструю (по ключевым операциям, "чтение и поиск", "запись" и "удаление")
2. Демонстрации сервиса автоматического создания многофункциональных полноценных IT-платформ из файла Excel, который заполняет обычный человек (не программист).
А результатом является: действующие и взаимодействующие нативные мобильные приложения, адаптивный сайт (то есть, и обычный, и мобильный), весь бэкэнд, сервер, база с "сычёвской архитектурой" 5-ой версии и пр.
А также там есть сервис и для программистов, которые пишут специфические функции для своих проектов. Теперь можно писать "чистые функции" на сервере (например, на python, php или любом ином серверном языке, который Вы предпочитаете) и просто "складывать" их в определённое место, после чего всё, что надо создастся и в мобильном приложении, и во всех иных подсистемах.
Пользовательские интерфейсы приложений создаются автоматически в стандарте Гугл.Материал.Дизайн (точно лучше, красивее и эргономичнее, чем делают руками). То есть, это не "конструктор".
При всём, при этом, данные (равно и сервер в целом) могут находиться на стороне Пользователя - то есть, можно получать сервис из "облака", а данных держать у себя (если на то есть желание); более того, они вообще "не ходят" через сервис, а все функции выполняются.
Последнее важно для B2B-проектов, где компании не хотят отдавать данные в "облако", а также это важно для разработчиков проектов на заказ, которые не хотят показывать своих Клиентов сервису, тем более, не хотят передавать в чужое "облако" их данные, но сам сервис получать хотят. Мы действительно не видим Ваших Клиентов, не знаем Ваших проектов, Вы контролируете весь код и все данные.
Мы приглашаем пока персонально, а также Участников и Читателей этого обсуждения. Ваше мнение для нас очень ценно, а мы тоже надеемся, что Вам будет интересно.
Пожалуйста, присылайте заявку, отправив простое письмо по адресу sch@triz-ri.com , указав в поте Тема/Sugj слово OWLS. Если Вы нажмёте на эту ссылку здесь, такое письмо может автоматически сформироваться.
Большое Спасибо,
На ту же тему
- Статьи по теме
- Обсуждения по теме
- Готовые решения по теме
Действительно, создать качественную программу "из объектов", двигаясь "снизу вверх" (от подсистем к системе; от реализации к проекту), можно только при условии предельной простоты такой программы.
Однако, похоже, существует инерция мышления, оставшаяся с тех времен, когда все писали на низком уровне, и мысли о реализации неизбежно занимали наибольший промежуток времени. И многие программисты (конечно, не все) часто думают "снизу вверх". Больше над реализацией, чем над проектом.
Но, например, хороший архитектор никогда не проектирует дом "из квартир", а думает о нем сразу "в целом", "вписывает" в контекст окружающей среды, пользуется знаниями о готовых "стилях" (или создает свой стиль, зная о других). Хороший авиаконструктор не проектирует новый самолет "из его элементов", но пытается понять, как машина "летает в целом", или отталкивается от "принципов полета этого класса машин" и т.д., и т.п.
Мышление "снизу вверх" сродни попытке сложить организм из атомов углерода и водорода. Теоретически так сделать можно, но очень уж "многофакторно" и затратно как по времени, так и по ресурсам. И все равно, несмотря на затраты и при квалифицированной работе, получится урод + "теория неизбежности ошибок" вместо качественного продукта. За исключением, может быть, тех случаев, когда "организмом" (перепутав термины) назвали что-то предельно простое (например, 1 звено СН).
Эта парадигма создавалась из утилитарного стремления к идеалу, как в управленческом, так и в тризовском смысле. Формулировки идеальности (которые соответствуют по духу и замыслу тем, что сформулировал Генрих Альтшуллер, создавая ТРИЗ, и которые продвигали эту разработку) следующие:
1) Идеально - это когда программу сможет в отсутствие Автора не только сопровождать, но и развивать программист с меньшей квалификацией, чем Автор программы.
2) Идеально - когда добавление новой функциональности в программу не потребует внесения изменений и/или добавлений в программный код (более того, в совершенно идеальной программе увеличение функциональности приводит к сокращению кода); причём всё это без ущерба для любых параметров (например, быстродействия и т.д.).
И чтобы программы писались настолько быстро и сопровождались настолько просто, что их создание и сопровождение можно было бы поручить детям. А взрослые и умные специалисты пусть бы занялись чем-нибудь великим.
Данная закономерность была сформулирована автором в 1993 году в Иркутске. Ряд фактов уже тогда давали возможность построить модель, которую, тем не менее, нужно было проверять в течение долгого времени. Последующие 13 лет позволили сделать ряд обобщений, подтвердивших изначальную гипотезу. И в 2006 году автор счёл возможным первую версию закономерности опубликовать открыто.
Летом 2013 года публикуется версия 2.0 - более полная, развернутая и содержащая одно существенное методическое отличие от первой версии.
Автор будет признателен Коллегам, которые найдут "узкие места" данной работы и направят автору критические замечания и/или примеры, как подтверждающие, так и опровергающие положения изложенные в материале.
Часто бывает так: людей на работу взяли, а дело не движется. Звонков мало, заявок еще меньше, клиентская база тает… И не только в отделе продаж.
А Вы возьмите к себе "на работу" наших специалистов.
Каждый из нас имеет более чем 20-летний опыт практического внедрения системы управления предприятием, администрирования бизнес-процессов в отделах: активных продаж, закупки (снабжения), продвижения, складском хозяйстве, бухгалтерии, IT и пр.
С нашим приходом на предприятие уже через короткое время процессы управления организацией начинают работать как хорошо отлаженный механизм. А штатные сотрудники привыкают выполнять свои функции.
Если Вы бываете в Европе по делам бизнеса или с частными целями, найдите время заехать к нам в Прагу. На консультацию, на стажировку, на деловой завтрак. За свежими идеями, за новыми методиками, за иной обстановкой и за иными возможностями.
В Праге Вас встретят наши лучшие эксперты. Мы предложим Вам качественные программы бизнес-обучения по-европейски. В том числе, сделанные "под Вас". В том формате, в каком удобно Вам.
"ТРИЗ" - Теория Решения Изобретательских Задач – самая сильная, на сегодняшний день, система создания новых идей и изобретений известна во многих странах: Германии, Великобритании, США, Швеции, Франции, Японии, Корее, Израиле, Вьетнаме, Испании, Финляндии, Канаде и др.
Книги автора ТРИЗ Генриха Альтшуллера [15.10.1926 - 24.09.1998] переведены на десятки иностранных языков. Большинство успешных компаний активно используют её для совершенствования своих товаров и услуг.
Идея проекта и руководство: С.В.Сычёв
Редактор: О.И. Дейнега. Web-Master: Р.А. Лушов.
Политика конфиденциальности