Hulp gezocht bij maken van kruistabel

snap 'm niet helemaal maar heb 'n vermoeden welke kant dat uitgaat.
Echter het toekennen of intrekken van een rol gaat op basis welke functie iemand heeft. Niet meer niet minder. In sommige gevallen mag iemand niet meer dan een rol hebben. Om diverse reden is daar voor gekozen. Het zal ook niet om honderden mutaties gaan hoor. Maar tja zal vermoedelijk wel iets met veel selectboxen of misschien radio button zijn. Want er zijn maar twee smaken. Toekennen of intrekken. om maar wat te noemen... maar nogmaals heb hier geen benul van want nu handig is omdat ik niet de verschillende methodieken niet ken/weet.

Visueel is het gewoon een klikbare cel in plaats van een selectbox.

Al met al zijn rechtensystemen een leuke materie. Voor een project waar ik mij mee bezig houd heb heb ik dit aan de hand van een voorbeeld ingebouwd en aangepast. Maar je moet wel goed op papier zetten hoe je dit vorm geeft, zoals de database, als de classes als de vormgeving in het beheerpaneel.

- Ariën - op 20/08/2019 22:07:06

Hoe graag Dirk zou willen, als ik zijn eerdere post lees, kan hij weinig invloed uitoefenen op de opzet van de database.

Zou ik toch eens gaan praten met de lui die deze opgezet hebben en periodiek vullen dan.

Ik snap dat je het oorspronkelijke SAP systeem niet kunt wijzigen, en ook de CSV-bestanden die hier uitrollen niet. Ik snap alleen niet waarom je dat dan vervolgens ogenschijnlijk 1:1 in een database kiepert. Je kunt de data in de CSV-bestanden prima omvormen naar beter hanteerbare informatie. Hier kun je veel meer winst pakken. Ook het feit dat het MyISAM is volg ik niet helemaal. Klinkt gewoon als half werk.

kan klinken als half werk.... of klinkt het als onervaren.. Ik denk dat ik die laatste opmerking maar niet heb gelezen :-)

Wanneer iets MyISAM is kan je misschein niet begrijpen.. Ik heb dr geen flauwe notie van wat het inhoudt en wat het doet en wat de verschillen zijn. Maar is dat de vraagstelling?

In gesprek gaan met die lui van SAP zal lastig worden. Deze zitten in Zwitserland en om daar nu ff heen te tuffen.
Er is gekozen om de dumpbestanden as is in te lezen zonder om te vormen. Dit is een keuze. Daarnaast de wedervraag.. wat zou er dan omgevormd moeten worden?

Een database die MyISAM-tabellen bevat hangt letterlijk als los zand aan elkaar. Bijvoorbeeld de tabel idm_person2role zal het letterlijk worst wezen dat deze mogelijk een user-rol paar bevat die ofwel refereert aan een niet-bestaande user ofwel aan een niet-bestaande rol of allebei.

Misschien is dit inmiddels veranderd maar bij mijn weten kun je met de MyISAM-engine niet afdwingen dat de data in de verschillende tabellen overeen moet komen. Bijvoorbeeld als user #1 en rol #1 bestaan in hun respectievelijke tabellen, pas dan kun je rol #1 verbinden met user #1 in deze koppeltabel. MyISAM controleert dit niet omdat je geen regels kunt opstellen die dit afdwingen.

Ook zijn er geen voorzieningen voor het kloppend houden van verbanden, bijvoorbeeld dat als je rol #1 verwijdert dat de koppeltabel automatisch de user-rol paren met rol #1 verwijdert.

Dan voorkomt MyISAM ook niet dat als je allerlei informatie toevoegt of wijzigt (in een query-batch) en er gaat halverwege iets fout dat dan het hele feest niet doorgaat. De database is dan half bijgewerkt, en dat kan er voor zorgen dat informatie uit de pas gaat lopen.

Dit zou je natuurlijk allemaal programmatisch kunnen afdwingen, maar dat is veels te veel werk, foutgevoelig en daarnaast gewoon onnodig, immers...

InnoDB heeft al deze voorzieningen wél: je kunt regels op en tussen tabellen definiëren waarbij er echte relaties bestaan tussen deze tabellen die ervoor zorgen dat je informatie klopt en blijft kloppen. InnoDB kan ook gebruik maken van database-transacties waarbij je batches informatie in het geheel, of in het geheel niet wegschrijft. Dit zorgt ervoor dat de database-toestand altijd een kloppende is en niet vervuild wordt met incomplete data/wijzigingen. Dit alles lijkt mij in een administratief systeem "nogal belangrijk".

---

Wat er mogelijk omgevormd zou kunnen/moeten worden:
- mogelijk toevoegen van extra tabellen voor rapportages etc, dit hangt van je informatievraag/-vragen af? of het verder uitsplitsen van data (Level 1:Level 2:Level 3:Level 4:Level 5 *kuch*)
- verwijdering van hard coding tussen tabellen (maak gebruik van interne nummeringen waar we het over gehad hebben)
- mogelijke dataverrijking, je zou extra velden met extra (voor mensen leesbare) informatie kunnen toevoegen
- bedien je van eenvoudigere/andere tabel- en kolomnamen zodat je op een intuïtievere manier queries kunt uitvoeren en informatie kan opvragen (Level 1:Level 2:Level 3:Level 4:Level 5 *kuch*)

Oftewel met de KENNIS van het systeem kun je je import een gigantische boost geven zodat je database een goed georganiseerd register is waar je snel informatie uit kunt opvragen. Daar was deze hele exercitie toch voor bedoeld? Voor het geven van inzicht, dan zul je ook wat moeite moeten doen om een overzichtelijk iets te creëren. Als je dit gewoon 1:1 vertaalt dan is dat toch een beetje, om een maat te quoten, "shit in, shit out".

Als dat afdoende is, soit. Maar dat is tegelijkertijd een (groot) gemis in die zin dat je er mogelijk veel *meer* mee kunt. Je mist dan een heleboel potentieel omdat je nog steeds met dezelfde SAP-meuk werkt.

Mooi en leerzaam verhaal. Toch wil ik me afvragen of het voor mij werkbaar zou zijn om die energie in te steken met alle goede bedoelingen van dien. (Level 1:Level 2:Level 3:Level 4:Level 5 geneuzel was een eenmalig iets en wordt nergens anders toegepast en daar is een oplossing voor gekomen. Hulde..

Nu kan ik mijn energie steken in tabellen types en opsplitsen van samenvoegingen... maar uiteindelijk moet ik weer 'n output gaan genereren en dan die opsplitsingen weer samen gaan voegen. Want de output moet weer corresponderen met de SAP omgeving. Is het dat allemaal waard? Ik kan die inschatting niet maken.

Neem niet weg dat ik dit zeer leerzaam vind... Ondanks dat ik nog 'n nitwit ben zou ik ook een andere structuur gekozen hebben.

Alles in ogenschouw nemen kan ik het niet overzien of het wel/niet de moeite waard is en wat ik er bij gebaat ben omdat ik die andere methodiek niet ken en daar dan ook energie in moet steken. Tijd die ik eigenlijk daar niet voor heb.

jongens ... heb ff 'n blackout.... ik kan niet ontdekken waarom onderstaande niet werkt:

<?php
function m2r(){
		global $MySQL;
		
		if (isset($_POST['submit'])) {

			$naam = mysqli_real_escape_string($MySQL, $_POST['naam']);
			
		$aanmaken = "INSERT INTO `m2r` 
		
					(`naam`) 
		
					VALUES 
					
					('$naam')";

			if (mysqli_query($MySQL, $aanmaken)){
			echo '<h3">Er is een nieuwe naam toegevoegd aan de database</h3>.';
		}else{
			echo 'Sorry,'.mysqli_error($MySQL);
			}
		}
	
	?>
	<form action="?actie=m2r" method="post" enctype="multipart/form-data">
		<table cellpadding="3" border="0">
			<tr>
				<td><h5>Naam</h5></td>
				<td><input type="text" name="naam"></td>
			</tr>
			<tr>
				<td></td>
				<td><input type="submit" name="submit" value="Opslaan"></td>
			</tr>
		</table>
	</form>
	<?php
}
?>

ik ontvang de foutmelding: Warning: mysqli_real_escape_string() expects parameter 1 to be mysqli, null given in


ik wil nl een shot geven of het me lukt om via form de kruistabel te kunnen bewerken... maar dan met zoiets basaal de mist in :-)

Hoe ziet je connectie eruit?

<?php

$connection = mysqli_connect("localhost", "root", "");
$connection->set_charset('utf8');

if(!$connection){
	echo "Er kan geen connectie met de server worden gemaakt" . die(mysqli_error($connection));;
}
$dbselect = mysqli_select_db($connection, "bigpicture");
if(!$dbselect){
	echo "Er kan geen connectie met de database worden gemaakt" . die(mysqli_error($connection));
}
?>

Juist, $connection dus. :-)